Rick Troth writes: > I've never understood named sockets or how they differ > from named pipes. Prefix char is "s".
They are real sockets, living in the Unix domain rather than (for example) the internet domain. So just as the endpoints of a TCP/IP connection are sockets referenced by an IP address and a port number, so a stream connection in the Unix domain is between sockets referenced by a filesystem object with a path name like any other filesystem object. A TCP/IP application server creates a socket, binds it to a chosen [server IP address, portnumber] pair and listens for connections. A client creates a socket, binds it to its own [client IP address, random-portnumber] (often automatically) then does connect()s it to the server's well known [IP address, portnumber]. In the Unix domain, a server program creates a socket, binds it to a well-known pathname (e.g. /var/run/myapp) which creates a visible object there (the thing that ls shows with the "s"). A client creates a socket, binds to, say, $HOME/.myappclient/foo, and connects to /var/run/myapp. Like a TCP/IP application (and unlike named pipes) you can have multiple concurrent connections from clients to the same server (the server program sits in accept() which hands it out a new file descriptor for each new connection that arrives). Unix domain socket connections, similarly to TCP/IP, can choose between a stream-based connection (bidirectional stream of bytes) and a datagram one. Much more interestingly, though, Unix domain sockets support functionality that TCP/IP can't. Since both endpoints are in the same Unix system, you can pass Unixy information across them (with the help of the kernel): I'll mention two here. You can pass file descriptors across them--not just the number. A server can open a file and pass the file descriptor through the socket where it magically appears at the other end as an open file descriptor in the receiving process. Or a client can pass an open file descriptor to a server. This is different from just passing a name and getting the other side to open it: think about what happens when the processes on both sides have different security credentials (uid, gid etc); what happens when you pass a descriptor to an opened file with its seek pointer in the middle; what happens with an opened socket or an opened file that was then unlinked/removed before passing across the socket. (Trivia: any implementation of this requires a garbage collection algorithm in the kernel. As far as I know, this is the only part of a Unix-like kernel which absolutely requires a garbage collection algorithm.) You can also (on Linux systems--other Unices may have different APIs or be unable to do this) pass your identity credentials to the other side. This means that the server side program can receive the pid, uid and gid of the client side of each connection in an unforgeable way. It provides a good way for servers to mediate client security in the case that you don't want to mess with passwords and such like. A server daemon can, for example, restrict incoming admin connections to only those coming from a given uid. In the case of Linux, you can also set permissions on the server socket (a client will be unable to connect if it doesn't have read/write permission to that socket object) but most other Unices ignore socket permissions. For more details, "man unix" should pick up the Section 7 man page for Unix domain sockets. Hmm, that turned out to be a longer email than I intended. --Malcolm Malcolm Beattie <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
