You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use-case where I need to split up a payload into a series of Noise messages, but it's not clear to me what the most efficient chunk size should be.
The TransportState type (and related types) doesn't provide a way to know the maximum size of a payload for a single message. It just says that if the final message would be larger than the 65535-byte maximum that it returns an Err.
Looking at the code I know the tag is 16 bytes (so it works out to be 65519 bytes I guess), but that's not exposed to me through the API in a convenient way.
I'm envisioning an interface where you can supply a large &[u8] and have the encryption call return the number of bytes consumed from the slice, so on subsequent calls we can move forwards the beginning of the slice and continue.
The text was updated successfully, but these errors were encountered:
Hey @delbonis! Yeah, the maximum payload size for transport messages should really be exposed in the API, good point.
True that it'd be nice to have a convenience method for large payloads. I was thinking snow might benefit from having some convenience APIs that return Vec<u8>s anyway, so a method that takes a large payload chunk and returns a Vec<Vec<u8>> could be on the table too.
In the mean time, if you haven't checked out slice::chunks(), it makes this type of thing a lot cleaner even without a convenience method :).
I have a use-case where I need to split up a payload into a series of Noise messages, but it's not clear to me what the most efficient chunk size should be.
The
TransportState
type (and related types) doesn't provide a way to know the maximum size of a payload for a single message. It just says that if the final message would be larger than the 65535-byte maximum that it returns anErr
.Looking at the code I know the tag is 16 bytes (so it works out to be 65519 bytes I guess), but that's not exposed to me through the API in a convenient way.
I'm envisioning an interface where you can supply a large
&[u8]
and have the encryption call return the number of bytes consumed from the slice, so on subsequent calls we can move forwards the beginning of the slice and continue.The text was updated successfully, but these errors were encountered: