RE: What is the correct behaviour for local socket(AF_UNIX) in the following scenario?

On Fri, 25 Nov 2005, Mayank Kumar wrote:

> From this I understand that if p1 closes the socket, then all the data 
> written by it is discarded since the buffers associated with this socket 
> no longer exists.
> 	If that is the case, then this is not at all true that p1 can 
> write data on a socket and close it and exit and p2 will still be able 
> to retrieve the data written by p1. Does FreeBSD differ with solaris or 
> other unixes in this implementation. I believe that Solaris does support 
> the above scenario although I am not sure. Do you know How other unixes 
> behave here. Because it makes a lot of sense for localsockets to 
> facilitate IPC on a system by supporting the above scenario between two 
> processes.

I imagine most UNIXes take a similar approach to UNIX domain sockets, at 
least for stream sockets, as the file system reference socket is a 
rendezvous point to create new socket pairs that have the same properties 
as sockets created using socketpair().  It's possible to imagine 
alternative behavior in the datagram case, but I don't know of any such 
implementations.

There are several other message queue related facilities you may want to 
look at, which might provide more of the semantics you're looking for:

- POSIX "named pipes", or fifos.  Unlike with UNIX domain sockets, the
   file system name isn't simply a rendezvous using which communication
   instances can be created.  However, I think they may get flushed on last
   close.

- System V IPC message queues, which don't use the file system name space,
   but do have a notion of persisting beyond application reference.

- David Xu is working to create a POSIX message queue implementation
   currently, so it will likely be available in the near future.

Robert N M Watson

>
> Regards
> Mayank
>
> -----Original Message-----
> From: Robert Watson [mailto:rwatson_at_FreeBSD.org]
> Sent: Friday, November 25, 2005 5:54 AM
> To: Mayank Kumar
> Cc: freebsd-current_at_freebsd.org
> Subject: Re: What is the correct behaviour for local socket(AF_UNIX) in
> the following scenario?
>
>
> On Fri, 25 Nov 2005, Mayank Kumar wrote:
>
>> I am trying to understand the behavior of localsockets in the
>> following scenario.
>>
>> A process p1 writes a huge amoount of data to a AF_UNIX,DGRAM socket
>> and exits. Now if there is no process p2 to read the data written by
>> process
>> p1 from the same localsocket, then this has resulted in a huge memory
>> leak on a FreeBSD system.
>>
>> I want to understand, if there is a mechanism in FreeBsd to take care
>> of this leak or this is the expected behaviour and application writers
>
>> should take care of this situation. Also what should be the behaviour
>> on such a socket if shutdown or close is issued on such a socket. Any
>> help on the behaviour on other unixes in the same scenario would also
>> help a lot.
>
> Mayank,
>
> The key to understanding how this is handled is to understand that UNIX
> domain sockets aren't file system objects -- the file system simply
> provides a name space by which to reach the socket.  The buffers
> associated with UNIX domain sockets belong to the sockets, not to the
> name.  You can think of this in the same way as you might think of port
> numbers and IP addresses, although there are some subtle differences.
>
> There are two common operational modes for UNIX domain sockets: stream
> mode, and datagram mode.  In stream mode, a listen socket is bound to
> the name, and then new socket pairs are generated when that name is
> connected.
> In datagram mode, a single socket exists on the "server" end, and then a
> series of other sockets may send to it using sendto and send.  The
> buffers are associated with the active communication sockets in both
> case, so if all endpoints are closed, the name persists, but has no
> persisting buffers.  So a name can be leaked (i.e., not be unlinked when
> a process is done with it), which is similar to leaking a temporary file
> that isn't unlinked.
>
> Hope this helps,
>
> Robert N M Watson
>