Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce Message Size Limits #6

Open
sarvalabs-manish opened this issue Nov 28, 2022 · 0 comments
Open

Enforce Message Size Limits #6

sarvalabs-manish opened this issue Nov 28, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@sarvalabs-manish
Copy link
Member

sarvalabs-manish commented Nov 28, 2022

Enforcing Size Limits

  • Protocol Buffers messages have a hard limit of 2 GB because most implementations use signed 32-bit signed arithmetic (determines the max encodable tag value). Google's official implementation enforce a hard limit of 64 MB because the entire message needs to be loaded into RAM to be decoded. Read More
  • Currently go-polo does not enforce any size limit and uses 64-bit unsigned arithmetic and hence has a much higher potential size. This needs to be artificially limited to 64 MB to make the implementation crash tolerant while loading large messages into memory. There has been no instance of such crashes (yet) but better safe than sorry. (This must probably also be enforced by the specification across implementation)
  • Consideration for size limiting are only for free sized wire types:
    • Integers and Floats use under 8 bytes, Booleans use space and Varint Tags are a maximum of 10 bytes.
    • This leaves BigInt and Word as the atomics that can have arbitrary sized data. (need their own size limit enforcement)
    • Pack and Doc encoded data must implicitly ensure that the size of sub-elements collectively does not exceed the size limit. This check will filter down to arbitrary sized encoding as their encoded output will be rejected by the pack data.

Implementation Approach

@sarvalabs-manish sarvalabs-manish added enhancement New feature or request backlog Non urgent enhancement or bug labels Nov 28, 2022
@sarvalabs-manish sarvalabs-manish self-assigned this Nov 28, 2022
@sarvalabs-manish sarvalabs-manish removed the backlog Non urgent enhancement or bug label Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant