summaryrefslogtreecommitdiffhomepage
path: root/Val.hs
Commit message (Collapse)AuthorAge
* add license headers to all source filesJoey Hess2017-04-30
|
* switch wire message seralization to use protocol buffersJoey Hess2017-04-27
| | | | | | | | | | | | | | | | | | | | | | | | This way it's not tied to details of the haskell binary library, and implementations in other languages should be fairly simple to do. The haskell protobuf library was used because it does not need extra tooling or build steps. So I didn't write a .proto file, but one could fairly easily be written by following ProtocolBuffers.hs and translating it. ProtocolBuffers.hs is *extremely* repetative and tedious code. Surely there must be a way to not need to write all of that? Oh well, I wrote it.. Sizes of serialized messages: ">>> debug-me session started": 121 sending a single key press: 169 This seems equally as efficient as the binary serialization was; that was 165 bytes before elapsedTime was added. This commit was sponsored by Ethan Aubin.
* initial http serverJoey Hess2017-04-21
| | | | | | | | | | | | Incomplete, but the client is able to connect and send messages which get logged. Split up debug-me.hs into Role/* Switched from cereal to binary, since websockets operate on lazy ByteStrings, and using cereal would involve a copy on every receive. This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
* use cereal for efficient serialization for wire formatJoey Hess2017-04-21
| | | | | | | | | | | I tried both binary and cereal. For a ActivityMessage that takes 341 bytes in JSON and has a dataSize of 129, both used 165 bytes. Went with cereal since lazy bytestrings are not needed, and I might want to use https://hackage.haskell.org/package/safecopy later. (Perhaps I should be using protocol buffers or something to make it easier for non-haskell implementations? But that would complicate things a lot.)
* memory DOS preventionJoey Hess2017-04-18
| | | | | | | | | | | | Prevent DOS of user side by limiting the size of the BackLog that is maintained. This should not cause problems in even high latency environments, and should prevent memory use > 16 mb. The developer side does not keep much data, other than a list of the Hashes of things it has recently sent, so is not susceptable to memory DOS. This commit was sponsored by Brock Spratlen on Patreon.
* improve JSONJoey Hess2017-04-14
Most of the time, ByteStrings will be able to be encoded as utf8, so avoid base64 when not needed. Adjusted some of the types in order to generate more usual JSON. In particular, removed StartActivity. The JSON now looks like this (with the signature still not populated): {"signature":{"v":""},"prevActivity":{"hashValue":{"v":"3b1abe614dd43bdb2d9a56777884e2d0f3bac9796e2d25c1ad52bb689c117286"},"hashMethod":"SHA256"},"activity":{"echoData":{"v":""},"enteredData":{"v":"l"}}} 203 bytes to send a single keystroke is not great when there's really only 1+64(hash) bytes of unique data. So, may end up adding a wire encoding on top of this. But, JSON is good to have for storage of the proofs, etc. Also, it does compress well. Two such JSON objects gzip -9 to 219 bytes, and three to 265 bytes. So, 37 bytes per keystroke. This is *exactly* as efficient as gzip -9 of $c$hash formatted data. This commit was sponsored by Jack Hill on Patreon.