Re: [tae] sockets vs. fds

* 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.
_______________________________________________
tae mailing list
tae@ietf.org
https://www.ietf.org/mailman/listinfo/tae