Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
TCP/IP has some binary header fields which are affected by byte order, so defines 'network byte order' to settle the issue, specifically defines it as big-endian.
When was this decided? The earliest reference I've found so far is RFC 1700, but that seems to be dated 1994, and I would expect this matter to have been decided much earlier than that.
As far as I can see, RFC 1700 doesn’t define “network byte order” as a phrase; it specifies the order of transmission of bytes (or octets) on the network, as done previously in the RFCs it obsoletes (going at least as far back as RFC 990 in November 1986). As I understand it, “network byte order” is just the order of bytes on the network, which depends on the network and should be documented in the network’s specification — it’s big-endian for IP, as documented in the IP specification, RFC 791, published in September 1981. (The initial TCP paper doesn’t concern itself with such issues.)
Endianness as a byte-order term goes back to Danny Cohen’s On Holy Wars and a Plea for Peace, published as Internet Experiment Note 137 in April 1980 and again in IEEE Computer Magazine in October 1981. That paper summarises the situation, pointing out that many existing communications protocols are little-endian (RS-232, Telex…) but that the ARPANet IMP was mostly big-endian, and that communications on the ARPANet were big-endian.
For TCP/IP, the matter was "decided" the first time an IP packet was sent. The order of bits and bytes put onto a wire (or a radio link) by the sender had to match the order they were processed by the receiver. If the receiver processed them in a different order, chaos ensued.
Since all communication involved at least two parties (a sender and a receiver), the appropriate order was established by convention. If you followed the convention things worked; if you didn't then things didn't work.
Eventually someone saw fit to actually specify the conventional order in an RFC, but before that you could figure out what the correct order was by trying to communicate with another already-working system. I would not be surprised if repeated failures due to incorrect assumptions is what led this to being included in RFC 791, when it had been unstated in RFC 760 and IEN 123.
Keep in mind, it was not typical to write the RFC/IEN first, then build a system afterward. Rather, you built a prototype first, refined it through multiple iterations, and then when you finally had something that worked well enough to share with others, you would document it in an RFC or IEN (although sometimes you'd do so even if it wasn't working "well enough" simply to meet a commitment).
Network packets are formed once but read during transmission multiple times. Therefore it is worth optimizing reading of multi-byte values. Reading a big-endian unsigned number consisting of N bytes (where N bytes is no more than the native word size) is
cnt = N;
val = 0;
while (cnt--) val = (val << 8) | getbyte();
whereas reading a little-endian number requires a more complex code, something like
val = 0;
for (cnt = 0; cnt < N; ++cnt) val |= getbyte() << cnt*8;
Therefore reading a value transmitted as a big-endian byte sequence is more efficient.
htonl etc. to convert from network order to host order or vice versa. And I seriously doubt there was ever any hardware where you really read packets one byte at a time.
YY-MM-DD hh:mm:ss.dddisn't a very interesting answer.