🚀 go-pugleaf

The 4.2 BSD socket interface passes all addresses and port numbers 
to and from the kernel in network byte order. I believe there is
a good case for the alternative, namely host byte order, and
I am curious to know why the former was chosen. Is network byte
order a DOD requirement?

At present, the various library routines for looking up service names
and port numbers, (e.g. getservent), automatically convert values
to network byte ordering. This is fine if you use the routines,
(and you probably will for internet addresses), but for something
simple like a port number, you might not bother, in which case you
could easily be caught out by not using "htons" or whatever. 

Switching to host byte order would actually give a simpler interface,
because programs using the library routines wouldn't be affected,
whereas programs which have to worry about this subtlety at the moment
would no longer need to do so, and could therefore be simplified.
I don't see that there has to be such a strong relationship between
the physical representation of the addressing in the network packet,
and the logical programming interface.

BTW, I'm not suggesting that the rest of the datagram be in host order(!), 
but simply that all the address fields should be. Dealing with arbitrary
data representation is a very different matter, best handled by proper
standards. 

I've just been doing my own UDP/IP implementation and looking at
the Berkeley code, and I found this feature of the interface
very confusing. It seems so much more natural to do the address
conversion inside the kernel, where all the other fields in the
various headers are byte swapped. Why should you have to swap
the port number, but not the length when you call send or receive??

A second point. Why bother to have a routine to convert to network
byte ordering, and another one to convert back again, e.g. "ntohl"
and "htonl"? Surely on any sane architecture, the transformation 
is its own inverse! Or is there really a machine out there which 
orders the bytes in its longs as 1,2,3,0? (:-)

Any comments?

Robert J Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.

UUCP ...!ukc!cheviot!robert
ARPA robert%cheviot%newcastle.mailnet