John Day wrote: >> >> Wouldn't it have been nice if the de facto APIs in use today were more >> along the lines of ConnectTo(DNS name, service/port). > > That had been the original plan and there were APIs that did that. But > for some reason, the lunacy of the protocol specific sockets interface > was preferred. About the time I wrote my second network app (circa 1986) I abstracted all of the connection establishment stuff (socket, gethostbyname, bind, connect) into a callable function so that I wouldn't have to muck with sockaddrs any more. And I started trying to use that function in subsequent apps. What I generally found was that I had to change that function for every new app, because there were so many cases for which merely connecting to port XX at the first IP address corresponding to hostname YY that accepted a connection, was not sufficient for the applications I was writing. Now it's possible that I was writing somewhat unusual applications (e.g. things that constrained the source port to be < 1024 and which therefore required the app to run as root initially and then give up its privileges, or SMTP clients for which MX processing was necessary) but that's nevertheless what I experienced. These days the situation is similar but I'm having to deal with a mixture of v4 and v6 peers, or NAT traversal, or brain-damage in getaddrinfo() implementations, or bugs in the default address selection algorithm. With so much lunacy in the how the net works these days, I regard a flexible API as absolutely necessary for the survival of applications. Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf