From: swhite@tybse1.uucp (William C. "Spike" White)
Subject: Re: Multiple listeners on same socket
Organization: Tybrin Corporation, Shalimar, FL
Date: Sun, 26 Jul 1992 05:00:45 GMT
Summary: helper processes w/ shared memory
Keywords: shared memory, sockets, IPC 

In article <1992Jul23.084108.22337@rdg.dec.com> jfoy@narcy.gao.dec.com (John Foy) writes:
>
>In article <1992Jul22.034730.12159@menudo.uh.edu>, nagappa@menudo.uh.edu (Chaitanya Nagappa) writes:
>|>[...]
>|>Howdy all,
>|>I need something equivalent to a socket, but that more than one process
>|>can listen on. This is for multiple consumers, and the output from the
>|>server can be picked up by any one of the consumers. In the simplest
>|>scenario, I have two processes doing a "listen" on the same socket,
>|>and only one of these process is trigerred to establish the circuit.
>|>Yes, I know neither BSD sockets or TLI can do this. What is then the
>|>alternative? Do I have to create my own virtual device?
>|>
>|>Message queues & FIFOs are not a viable alternative, as the information
>|>once placed cannot be ...
>|>[...]
>|>The problem of statically placing this using standard IPC methods such as
>|>message queues, FIFOs or shared memory is that by the time my processes
>|>get around to receiving the info. (worst case scenario) the call might
>|>have been cleared. So I need a phased communication of the info.
>
>I'm not sure what you mean by "phased communcation..."?
>
>I'm not entirely familiar with select etc... (being more of a VMS'r) but have
>you considered semaphores? e.g. the server pool waits on a counting semaphore
>which is incremented by the 'dispatching' process (I think you refer to this as
>the 'spawned' process)...? This way only available servers respond...
>
>
>	jf

I may be thinking of the same thing in UNIX terminology.  You would potentially
have several programs, all reading and writing from some inter-process
communication channel (semaphore, message queue or shared memory).  Let' pick
shared memory -- it's the most versatile (and hardest to code?). 

One program would be your true server.  It would wait for client requests to
appear in a designated portion of this shared memory.  It would write responses
to another designated portion of this shared memory.  It would not have any
networking code in it at all.

A second program would be a simplified inetd-like program.  That is, it would 
listen for network connections from clients at a well-known TCP port number.  
When it got a connection, it would fork (& exec?) a child to satisfy the 
client's requests.  Then it would go back listening for more connections.

The child process would be just a "helper" process for the client. It would 
read to and write from shared memory and the inherited socket. 

I think this is how some SQL server programs are implemented (except MUCH more 
efficiently :-)). 

You might be able to coalesce the inetd-like network listener and the child
"helper" programs also.  Listen for connections, if you get one add it to the
appropriate filemask, then do a select() and sequentially satisfy all clients
requesting info.  You'd still use shared memory w/ a "back-end" true server.
Sounds difficult to code.

Or you might coalesce the "back-end" server into the inetd-like listener, too. 
That saves the shared memory coding -- client requests would be looked up 
in the program's memory -- but it sounds EXTREMELY difficult to code.  You'd
still listen for connections, add to the filemask, do a select() and satisfy
all clients requesting info.



-- 
Spike White     Tybrin Corporation, Shalimar, FL | Moderation in all things --
swhite@afseo.eglin.af.mil                        | and abstinence in none! 
Disclaimer: I speak only for myself, not my employer. 
Xref: sparky comp.unix.internals:1634 comp.unix.questions:9586