about byte order

[wtao0221]

Hi,

(Sorry for those random questions, just want to get deeper understanding of mvfst)

For example, for the receiving path in https://github.com/facebookincubator/mvfst/blob/main/quic/codec/QuicReadCodec.cpp#L254, is the data already host byte order, if we want to decrypt it, do we need to follow some byte ordering?

for the sending path in https://github.com/facebookincubator/mvfst/blob/main/quic/api/QuicTransportFunctions.cpp#L338, is the packet already in network byte ordering?

so, what is the general discipline about byte ordering in host, network, and mvfst QUIC implementation?

BTW, how to join mvfst slack channel, maybe that is the place to post such quick questions?

[hanidamlaj]

Hey @wtao0221,

Thanks for your patience! The data parameter here is the packet as it was read off the wire (i.e. network order). In the function QuicReadCodec::tryParseShortHeaderPacket we later make a call to parsePacketNumber() where it reads the encoded packet number using folly::Endian::big(encodedPacketNum) to convert from network to host ordering.

For the sending path that you linked here, the header struct is in host order (as that’s how your computer orders a sequence of bytes in memory). However shortly after when we invoke scheduler.scheduleFramesForPackets()[https://github.com/facebookincubator/mvfst/blob/main/quic/api/QuicTransportFunctions.cpp#L342=L343], result.packet contains the packet in network order.

As a general rule of thumb I use, any data stored in a folly::IOBuf during packet writing/reading tend to be network order – more specifically the moment when the packet is read off the wire or before the packet is written to the wire.

[hanidamlaj]

Please feel free to re-open this issue if you have any other questions!