* Tony Finch:
On Fri, 5 Dec 2008, Dave CROCKER wrote:
Melinda Shore wrote:
Not to go too far afield, but I think there's consensus among us old
Unix folk that the mistake that CSRG made wasn't in the use of
addresses but in having "sockets" instead of using file descriptors.
This was actually fixed in SysVRSomethingOrOther with the introduction
of a network pseudo-filesystem (open("/net/192.168.1.1", ... ) with
ioctls but never got traction.
It isn't immediately obvious to me why file descriptors would have had a
major impact, so can you elaborate?
This isn't a question of sockets versus file descriptors, since
sockets *are* file descriptors.
In any case, now that more and more protocols use TLS, if you encode
the a-socket-is-a-file-descriptor assumption too heavily (for example,
by using descriptor passing and expecting that it preserves all
connection state) in your application, you might run into significant
problems very soon.
It is actually a question of how to specify network addresses in the
API, i.e. the BSD sockaddr structure versus the Plan 9 extended
pathname semantics. Using pathnames for everything would eliminate
warts like embedding pathnames in sockaddrs in order to address a
local IPC endpoint. On the other hand, filesystem pathnames are a
uniform hierarchial namespace, which isn't true for the combination
of network protocol, address, and port - what happens if you
opendir("/net/")?
Some people have already mounted more classic file systems with
practically unenumerable directories. 8-/
I really wish there were a standard textual representation of socket
addresses. A couple of years ago, when I was younger and had high
hopes, I designed something for Ada which used
INET/127.0.0.1/80
INET6/::1/80
LOCAL/var/run/server.socket
and so on, and thought it was pretty neat. But I haven't seen few
efforts in this area, maybe it's not that useful after all.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf