servers, clients, named pipes, sco & perl

servers, clients, named pipes, sco & perl

Post by Roderick Schertle » Wed, 01 May 1996 04:00:00


> Apparently, there is no way to look at a messeage in a named pipe to
> determine if its for you.

I don't know what SysV release the SCO you're using is based on.  You
might be able to do this using an I_PEEK ioctl(), see streamio(7).  If
you go this way be sure to use some sort of interlocking among the
clients to eliminate the race condition inherent in peeking at and then
reading from the pipe.

Quote:> This makes having multiple clients waiting for a reply very
> cumbersome.  [...]  The server is written in RM Cobol so it doesn't
> support tcp/ip or Sys V IPC - Are there any alternatives ??

If the server is writing messages meant for multiple clients to a single
named pipe (and you need to restrict your code to vanilla Unix) then
there is no trivial answer.  Your best bet might be to write an
intermediate server which would de-multiplex the output from the Cobol
server.  The intermediate server would read from the named pipe that the
Cobol program is writing to and then turn around and write the just-read
message to one of another group of named pipes, one of which exists for
each client.  (The end-clients would create a named pipe and then
contact the intermediate server, telling them their ID (whatever it is
that the Cobol program is writing out) and the name of the pipe the
intermediate server should send data to.)

An advantage of this approach is that you could use any form of IPC for
the communication between the clients and the de-multiplexor.  If you
used TCP sockets (and you extended the server so that data going from
the clients to the Cobol program also passed through it) you would be
able to run the clients on any host.

Quote:> Are named pipes the Unix equivalent of message queues ??

No, SysV IPC contains actual message queues.  Generic Unix pipes don't
have the necessary functionality.

PS:  This question is really best for comp.unix.programmer, I'm
crossposting and redirecting followups there.

Roderick Schertler