NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/internal/1620

Text File | 1992-07-26 | 3.9 KB | 83 lines

Newsgroups: comp.unix.internals
Path: sparky!uunet!xavax!tybrin4!tybse1!swhite
From: [e-mail] (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
Message-ID: <[e-mail]>
Summary: helper processes w/ shared memory
Keywords: shared memory, sockets, IPC
References: <[e-mail]> <[e-mail]>
Lines: 70

In article <[e-mail]> [e-mail] (John Foy) writes:
>
>In article <[e-mail]>, [e-mail] (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 --
[e-mail]                        | and abstinence in none!
Disclaimer: I speak only for myself, not my employer.