sockets vs. STREAMS, also intermachine networking on SV

[Kenneth Almquist]

> 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