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
structApplicationPacket{header:PacketHeader,message:Message,}pubstructPacketHeader{pubbuffer_size:u32,// contains length of Message in bytes}pubenumMessage{NoOperation,RegisterDevice(RegisterDevicePacket),// 54 bytes longUnregisterDevice(UnregisterDevicePacket),// 1 byte longInitiateConnection(InitiateConnectionPacket),// 32 bytes long}
Reading this from a std::net::TcpStream is trivial: ApplicationPacket::from_reader((&mut stream, 0)); However, when combined with async streams, this becomes much more involved. First I read the header, which contains the size of the rest of the message. Then I read PacketHeader::buffer_size bytes, concat that with the header, and parse the whole thing with ApplicationPacket::from_bytes.
This works, but is susceptible to attacks and dumb mistakes. buffer_size can be incorrectly specified in either direction, leading to either not having enough data to parse the full message, or halting the process until enough additional data has been passed to the TCP stream. I can protect against the latter case by comparing the buffer size with a predefined max size, and aborting the process before it finishes, but that's not a reliable solution.
Is there a way to not have to rely on the stated buffer size for decoding without a compatible reader?
The text was updated successfully, but these errors were encountered:
I have a message format that looks like this:
Reading this from a
std::net::TcpStream
is trivial:ApplicationPacket::from_reader((&mut stream, 0));
However, when combined with async streams, this becomes much more involved. First I read the header, which contains the size of the rest of the message. Then I readPacketHeader::buffer_size
bytes, concat that with the header, and parse the whole thing withApplicationPacket::from_bytes
.This works, but is susceptible to attacks and dumb mistakes.
buffer_size
can be incorrectly specified in either direction, leading to either not having enough data to parse the full message, or halting the process until enough additional data has been passed to the TCP stream. I can protect against the latter case by comparing the buffer size with a predefined max size, and aborting the process before it finishes, but that's not a reliable solution.Is there a way to not have to rely on the stated buffer size for decoding without a compatible reader?
The text was updated successfully, but these errors were encountered: