status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add spec references to the Snappy DEVp2p EIP.

This commit is contained in:
Péter Szilágyi 2017-10-02 17:52:25 +03:00 committed by Hudson Jameson
parent 3e29ac9126
commit 0724db3048
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
EIPS/eip-devp2p-snappy.md
View File

@ -42,11 +42,13 @@ Important caveats:
* The handshake message is **never** compressed, since it is needed to negotiate the common version. * The handshake message is **never** compressed, since it is needed to negotiate the common version.
* Snappy framing is **not** used, since the DEVp2p protocol already message oriented. * Snappy framing is **not** used, since the DEVp2p protocol already message oriented.
*Note: Snappy supports uncompressed binary literals (up to 4GB) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (Snappy usually detects this case automatically).*
### Avoiding DOS attacks ### Avoiding DOS attacks
Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindy decompress messages, since they may get significantly larger than 16MB. Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindy decompress messages, since they may get significantly larger than 16MB.
However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory. This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols. However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (*[the stream starts with the uncompressed length up to a maximum of `2^32 - 1` stored as a little-endian varint](https://github.com/google/snappy/blob/master/format_description.txt#L20)*). This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols.
## Alternatives (discarded) ## Alternatives (discarded)
@ -188,5 +190,10 @@ $ python main.py block.rlp block.py.snappy
Yay, decompressed data matched provided plain text! Yay, decompressed data matched provided plain text!
``` ```
## References
* Snappy website: https://google.github.io/snappy/
* Snappy specification: https://github.com/google/snappy/blob/master/format_description.txt
## Copyright ## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).