|
|
|
|
|
by rkangel
723 days ago
|
|
This is reasonable, but a bit unfortunate specifically for TCP/UDP. The extremely strong convention is that all network protocols are "network byte format" which is Big-Endian. Obviously no issue for local IPC, but when things become published network protocols, little-endian makes me sad. |
|
This is really only relevant for packet headers, tho. What goes into payload is entirely up to the developer. There is no specific reason to keep endianness the same between TCP/UDP and its payload. As long as it's clear which one to use.
RFC1700 is marked as obsolete. IIRC, network order is big-endian is because it allowed faster packet switching? But we're at the point where I can do dual-border routing with DPI orders of magnitude faster than switches from that era can do basic switching.
Some people choose little-endian for payload because they are:
a) unaware of endianness and will discover a funny thing when they suddenly start talking between BE and LE nodes. Rust forces you to choose when you write or read numbers.
b) Think since their CPU is LE then payload should be LE as well for performance. This is false because even on ancient hardware this would not take more than 3 cycles (in a context of network communication shaving off 3 cycles is a hilarious endeavor)
c) Aware of all of this and choose LE because they felt like it.