BSD Unix domain sockets (was Re: Here's the flame everyone's asking for)

[John Myers]

In article <47 at kenobi.UUCP> ford at kenobi.UUCP (Mike Ditto) writes:
>In article <997 at PT.CS.CMU.EDU> jgm at K.GP.CS.CMU.EDU (John Myers) writes:
>> [...]
>> Then why the heck can't you open(2) a BSD unix domain socket? [...]
>
>The main reason that I see is that a Unix domain socket is not really
>supposed to show up in the filesystem, and it supposedly doesn't in
>more recent BSD releases (4.3?).  I don't think it has ever been clear
>whether the "Unix domain" of socket names(addresses) is really
>supposed to map into pathnames in the ("open"able) filesystem.  Is it
>possible to bind an AF_UNIX socket to "/foo/bar/baz" if there is no
>directory "/foo"?  [...]

On a 4.3 system (IBM RT/PC), I tried binding an AF_UNIX socket to
"/foo/bar/baz" and got ENOENT.  I was also able to bind a socket to
"//tmp/foo" and connect to it by specifying "/tmp/foo".

I don't see why sockets shouldn't be in the filesystem.  They can be
read from and they can be written to.  That's more than can be said
for some of the things in /dev.  If they could be opened, they would
be almost as useful as System V named pipes.

>> Something that would be harder, but would still be incredibly useful
>> would be to automaticly unlink a socket when the (last) process owning
>> that socket exits.
>
>That would be inconsistent with files, which are not unlinked under those
>circumstances.  [...]

Yes, this is inconsistent.  The problem I am addressing is that when a
process binds a UNIX domain socket and then exits, there is this
useless zombie socket which gets left behind.  Attemting to bind to it
gets EADDRINUSE.  Attempting to connect to it gets ECONNREFUSED.  The
only reasonable thing that one can do with it is unlink it.

Perhaps a more reasonable behavior would be to have a bind to an
existing socket address succeed if no process owns a socket with that
address.

-- 
John G. Myers			jgm at k.gp.cs.cmu.edu