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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf