Xref: utzoo comp.unix.wizards:14691 comp.unix.questions:11694 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!ka From: ka@june.cs.washington.edu (Kenneth Almquist) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: sockets vs. STREAMS, also intermachine networking on SV Summary: Use messages for local IPC under System V. Message-ID: <7271@june.cs.washington.edu> Date: 14 Feb 89 20:20:50 GMT References: <438@laic.UUCP> <11191@ulysses.homer.nj.att.com> <510@gonzo.UUCP> Distribution: usa Organization: U of Washington, Computer Science, Seattle Lines: 35 > The point is that generic SVR3 does not, by default, contain a usable > local IPC mechanism for use by a server supporting multiple simultaneous > connections. Local IPC was added to AT&T UNIX before the first release of System V. See msgget(2), msgop(2), and msgctl(2). There is nothing along the lines of "select" for message queues, but you don't need it. The scheme works like this: - When the server starts up, it calls msgget to create a message queue with a known key. It then reads and processes requests from this queue. Each request includes a message queue identifier indicating where the response to the request should be sent. - When a client wants to start a conversation, it calls msgget to obtain the message queue identifier of the server's message queue. It then calls msgget again with a key of IPC_PRIVATE to create a queue to accept responses. The message queue identifier of this latter queue is included in all requests to the server. - When the client is done talking with the server, it should call msgctl with the IPC_RMID command to remove the message queue. - Clients which terminate abnormally may leave message queues around, so you want to remove message queues with a key of IPC_PRIVATE which have not been used for a while. You can use the ipcs command to identify these, and either remove them manually or have a daemon remove them periodically. You can determine when a message queue was last used using the -t option of ipcs(2) or the IPC_STAT command of msgctl(2). If you later decide to allow the server to be on a different machine than the client, you can write a pair of stub processes to forward requests across the network in a manner that's transparent to the client and the server. Kenneth Almquist