From owner-freebsd-current@FreeBSD.ORG Fri Nov 25 11:22:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A3C416A41F for ; Fri, 25 Nov 2005 11:22:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1429F43D45 for ; Fri, 25 Nov 2005 11:22:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EE00146B90; Fri, 25 Nov 2005 06:22:06 -0500 (EST) Date: Fri, 25 Nov 2005 11:22:06 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mayank Kumar In-Reply-To: <3A5384BC2FBA4C488865F2275A036BFF040B285D@APS-MSG-01.southpacific.corp.microsoft.com> Message-ID: <20051125111526.H81764@fledge.watson.org> References: <3A5384BC2FBA4C488865F2275A036BFF040B285D@APS-MSG-01.southpacific.corp.microsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: RE: What is the correct behaviour for local socket(AF_UNIX) in the following scenario? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2005 11:22:08 -0000 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@FreeBSD.org] > Sent: Friday, November 25, 2005 5:54 AM > To: Mayank Kumar > Cc: freebsd-current@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 >