robert@cheviot.UUCP (Robert Stroud) (05/01/85)
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