toivo@uniwa.uwa.oz (Toivo Pedaste) (02/23/90)
When a unix domain socket is opened by a server program it is created in the file system, but when the server program closes it and exits it continues to exist. Now when a client program is run it get an error saying that the socket is not connected, while when the server is run it gets an address already in use error. My question is does this now orphaned socket have a possible use or does it just get in the way. -- Toivo Pedaste ACSNET: toivo@uniwa.uwa.oz
evans@testmax.ZK3.DEC.COM (Marc Evans) (02/23/90)
In article <1990Feb23.023047.19975@uniwa.uwa.oz>, toivo@uniwa.uwa.oz (Toivo Pedaste) writes: > > When a unix domain socket is opened by a server program > it is created in the file system, but when the server program closes > it and exits it continues to exist. Now when a client program > is run it get an error saying that the socket is not connected, > while when the server is run it gets an address already in use > error. > > My question is does this now orphaned socket have a > possible use or does it just get in the way. This type of problem is typically due to the socket not being properly setup and closed down. After calling socket, it is often recommended that a call be made to setsockopt something like the following: setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,NULL,0); This will allow the address to be reused. The shutdown function is also recommended, such that anytime either side of the connection decides that it is done reading/writing, it is called to indicate so. Often, a signal catcher is useful to help with this, so that the exception cases are handled in a defined maner (such as cntl-c). Now, to answer your question, for most purposes, the "orphaned socket" is of no use to anybody, and should be removed when it is no longer in use. - Marc ========================================================================== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)893-8481 Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076 ==========================================================================
chris@mimsy.umd.edu (Chris Torek) (02/24/90)
>In article <1990Feb23.023047.19975@uniwa.uwa.oz>, toivo@uniwa.uwa.oz >(Toivo Pedaste) writes: >>When a unix domain socket is opened ... [the path name appears in the file system, and remains there even when the socket is defunct]. >>My question is does this now orphaned socket have a possible use or >>does it just get in the way. It just gets in the way. unlink() will serve to get rid of it. In article <6740@decvax.dec.com> evans@testmax.ZK3.DEC.COM (Marc Evans) writes: >This type of problem is typically due to the socket not being properly >setup and closed down. After calling socket, it is often recommended that >a call be made to setsockopt something like the following: > setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,NULL,0); SO_REUSEADDR does not apply to Unix domain sockets (see first line of >> above). The name space of Unix domain sockets is the file system, and there are no `incomplete' paths in the Unix file system. SO_REUSEADDR is intended to allow reuse of an `incomplete' name: since a connection that spans multiple machines automatically has at least two parts to its name (one on one machine, one on the other), and in the Internet naming scheme these two parts must remain separate for some time, it is possible to have duplicate `partial names'. An Internet socket `name' is the quad <local-address, local-port, remote-address, remote-port>. Each unique quad names one possible socket. The BSD bind() call refuses to allow non-unique <local-address, local-port> pairs `just in case', and typically local-ports alone give a unique socket ID. If you need non-unique local port numbers, you can set SO_REUSEADDR. Incidentally, the call quoted above is wrong. The fourth and fifth arguments to setsockopt should never be NULL and 0. 4.2BSD ignored them; 4.3BSD does not. To *en*able SO_REUSEADDR, use int on = 1; err = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (caddr_t)&on, sizeof on); To *dis*able it, use int off = 0; err = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (caddr_t)&off, sizeof off); A `char' may suffice, but an `int' is Officially Correct. A nonzero value means `turn the option on', and a zero value means `turn the option off'. Other options have fancier values (e.g., SO_LINGER; SO_DONTLINGER has vanished). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris