socket
in [Unix Programming]
|
Prev: IPC based on name pipe FIFO and transaction log file
Next: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
From: Ian Collins on 6 Apr 2010 16:56 On 04/ 7/10 03:06 AM, Rainer Weikusat wrote: > Ian Collins<ian-news(a)hotmail.com> writes: >> On 04/ 3/10 10:03 AM, Rainer Weikusat wrote: >>> scott(a)slp53.sl.home (Scott Lurndal) writes: >>>> Rainer Weikusat<rweikusat(a)mssgmbh.com> writes: >>>>> >>>>> PF_UNIX sockets are the preferable method for IPC on a single >>>>> system. Also, the socket API itself is not tied to either protocol or >>>>> address families. >>>> >>>> preferable by whom? >>> >>> People who understand IPC. >> >> Certainly not those who use Solaris. > > Just because I am convinced that I am right doesn't necessarily mean I > actually am. But in absence of any factual statements about the topic, > I additionally claim that "people who use Solaris and don't use > AF_UNIX sockets for local IPC" will usually be people "who don't > understand IPC" (additionally qualified as 'local IPC among otherwise > unrelated processes') and that 'use of RPC' is a sure sign of a > confused mind :->. Most recent (and a number of older) services on (Open)Solaris use doors for IPC. I assume you don't bracket Solaris kernel developers as people "who don't understand IPC". Doors provide a greatly simplified and higher performance IPC mechanism than UNIX domain sockets. A quick search for "door_create" in the OpenSolaris source will show you where they are used. -- Ian Collins
From: Ersek, Laszlo on 7 Apr 2010 06:09 On Tue, 6 Apr 2010, Rainer Weikusat wrote: > Assuming that 'socket I/O' is sufficient, using PF_UNIX sockets for > local IPC is sensible ... > >> [snip] > > ... because it avoids the overhead of carrying around all the 'internet' > protocol information for no particular reason and avoids using all the > TCP-mechanisms intended to cope with unreliable networks in situations > when there isn't a network. Minus socket creation, usage is (for the > 'common' cases) identical for both protocol families and offering > services on both types of endpoints can easily be done with the > standardized I/O multiplexing facilities (poll and select) and with > whatever extended ones are available. Another nice feature is the > availability of reliable datagram sockets, since this avoids the need > for writing code to work around bytestream semantics for record-based > protocols. (Quoting the whole paragraph for context only, my question relates to the last sentence.) Are you saying that SOCK_DGRAM sockets in the PF_UNIX protocol family (or according to the more recent socket() prototype / terminology, in the AF_UNIX domain) are reliable, for some definition of reliable? I'm not trying to set a trap for you, this is an honest question. Looking up SOCK_DGRAM and SOCK_SEQPACKET in the following SUSv4 specs: <sys/socket.h>, recv(), recvfrom(), recvmsg(), send(), sendmsg(), sendto(), socket(), socketpair(), I think the properties of SOCK_DGRAM are orthogonal to the domain. IOW, I believe, if the receiver process' socket buffer is full, even a blocking send() operation is allowed to return without error (or more precisely, even further operations on the sending socket are permitted to return without error) and still lose the message -- the kernel is permitted to throw away the message between the sending and the receiving socket buffers, after it has placed the datagram successfully in the outgoing skb when the sending process called sendmsg(). The XSH/2.10.6 "Socket Types" section says, ----v---- The SOCK_DGRAM socket type supports connectionless data transfer which is not necessarily acknowledged or reliable. Datagrams may be sent to the address specified (possibly multicast or broadcast) in each output operation, and incoming datagrams may be received from multiple sources. The source address of each datagram is available when receiving the datagram. An application may also pre-specify a peer address, in which case calls to output functions that do not specify a peer address shall send to the pre-specified peer. If a peer has been specified, only datagrams from that peer shall be received. A datagram must be sent in a single output operation, and must be received in a single input operation. The maximum size of a datagram is protocol-specific; with some protocols, the limit is implementation-defined. Output datagrams may be buffered within the system; thus, a successful return from an output function does not guarantee that a datagram is actually sent or received. However, implementations should attempt to detect any errors possible before the return of an output function, reporting any error by an unsuccessful return value. ----^---- I think rather SOCK_SEQPACKET should be used (see generic description in the same subsection of the SUSv4). In AF_UNIX, it should not place a disproportionately higher burden on implementors. I have no idea how widely (AF_UNIX, SOCK_SEQPACKET) is supported, though. <http://www.kernel.org/doc/man-pages/online/pages/man2/socket.2.html> says ----v---- Some socket types may not be implemented by all protocol families; for example, SOCK_SEQPACKET is not implemented for AF_INET. ----^---- This suggests Linux does implement (AF_UNIX, SOCK_SEQPACKET). I'm sorry if this horse had been beaten to death many times before. Thanks, lacos
From: Rainer Weikusat on 7 Apr 2010 15:47 "Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes: > On Tue, 6 Apr 2010, Rainer Weikusat wrote: >> Assuming that 'socket I/O' is sufficient, using PF_UNIX sockets for >> local IPC is sensible ... >> >>> [snip] >> >> ... because it avoids the overhead of carrying around all the >> internet' protocol information for no particular reason and avoids >> using all the TCP-mechanisms intended to cope with unreliable >> networks in situations when there isn't a network. Minus socket >> creation, usage is (for the 'common' cases) identical for both >> protocol families and offering services on both types of endpoints >> can easily be done with the standardized I/O multiplexing facilities >> (poll and select) and with whatever extended ones are >> available. Another nice feature is the availability of reliable >> datagram sockets, since this avoids the need for writing code to >> work around bytestream semantics for record-based protocols. > > (Quoting the whole paragraph for context only, my question relates to > the last sentence.) > > Are you saying that SOCK_DGRAM sockets in the PF_UNIX protocol family > (or according to the more recent socket() prototype / terminology, in > the AF_UNIX domain) are reliable, for some definition of reliable? I am saying that, when using SOCK_DGRAM (connection-less) and SOCK_SEQPACKET (connection-oriented) PF_UNIX sockets, datagrams cannot possibly just be 'lost' because of unpredictable network problems. For Linux, this type of communication is also documented as being reliable. I don't really know if the same is true for other implementations, except that dropping userdata for no particular reason wouldn't be a particularly sensible thing to do and I don't care for the possibility unless forced to by external circumstances. The way to get rid of broken implementations is to use features which are broken 'somewhere' and count on these implementations either dying out or being fixed.
From: Ian Collins on 7 Apr 2010 19:47 On 04/ 8/10 12:12 AM, Rainer Weikusat wrote: > Ian Collins<ian-news(a)hotmail.com> writes: >> On 04/ 7/10 03:06 AM, Rainer Weikusat wrote: >>> Ian Collins<ian-news(a)hotmail.com> writes: >>>> On 04/ 3/10 10:03 AM, Rainer Weikusat wrote: >>>>> scott(a)slp53.sl.home (Scott Lurndal) writes: >>>>>> Rainer Weikusat<rweikusat(a)mssgmbh.com> writes: >>>>>>> >>>>>>> PF_UNIX sockets are the preferable method for IPC on a single >>>>>>> system. Also, the socket API itself is not tied to either protocol or >>>>>>> address families. >>>>>> >>>>>> preferable by whom? >>>>> >>>>> People who understand IPC. >>>> >>>> Certainly not those who use Solaris. >>> >>> Just because I am convinced that I am right doesn't necessarily mean I >>> actually am. But in absence of any factual statements about the topic, >>> I additionally claim that "people who use Solaris and don't use >>> AF_UNIX sockets for local IPC" will usually be people "who don't >>> understand IPC" (additionally qualified as 'local IPC among otherwise >>> unrelated processes') and that 'use of RPC' is a sure sign of a >>> confused mind :->. >> >> Most recent (and a number of older) services on (Open)Solaris use >> doors for IPC. I assume you don't bracket Solaris kernel developers >> as people "who don't understand IPC". Doors provide a greatly >> simplified and higher performance IPC mechanism than UNIX domain >> sockets. > > 'Doors' don't provide an IPC mechanism, they use some kind of IPC > mechanism to provide 'remote procedure calls on the local > system'. This is easier to use for people who don't understand IPC > because it is conceptually identical to invoking ordinary subroutines. Yes, doors are a higher level of abstraction than "naked" IPC mechanisms. But people don't use them because they don't understand IPC, they use them because they provide a higher level of abstraction or better performance. I assume you understand assembler, but do you use that in preference to C? Your original claim was "PF_UNIX sockets are the preferable method for IPC on a single system", which I dispute. They have their place, but alternatives are often a better choice. -- Ian Collins
From: Rainer Weikusat on 8 Apr 2010 07:05
Ian Collins <ian-news(a)hotmail.com> writes: > On 04/ 8/10 12:12 AM, Rainer Weikusat wrote: >> Ian Collins<ian-news(a)hotmail.com> writes: [...] >>> Most recent (and a number of older) services on (Open)Solaris use >>> doors for IPC. I assume you don't bracket Solaris kernel developers >>> as people "who don't understand IPC". Doors provide a greatly >>> simplified and higher performance IPC mechanism than UNIX domain >>> sockets. >> >> 'Doors' don't provide an IPC mechanism, they use some kind of IPC >> mechanism to provide 'remote procedure calls on the local >> system'. This is easier to use for people who don't understand IPC >> because it is conceptually identical to invoking ordinary subroutines. > > Yes, doors are a higher level of abstraction than "naked" IPC > mechanisms. I knew this was hopeless, but - alas - ... doors are not 'a higher level of abstraction than IPC' because the very idea behind them is to hide the IPC-part away from people who do not understand the concept of 'communication between indepdendent entities' but who do understand, to some degree at least, the idea of dividing a complex task into subtasks which are implemented in form of subroutines orchestrated by some kind of 'master control unit'. Unless I am very much mistaken, I already tried to illustrate the difference with a very simple real-world example and an external reference and I don't see a point in repeating this here so that you can cut it away again. |