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

Text File | 1992-07-23 | 4.0 KB | 78 lines

Newsgroups: comp.unix.internals
Path: sparky!uunet!sun-barr!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!gateway.novell.com!ithaca!terry
From: [e-mail] (Terry Lambert)
Subject: Re: Multiple listeners on same socket
Message-ID: <[e-mail]>
Sender: terry@ithaca (Terry Lambert)
Nntp-Posting-Host: ithaca.eng.sandy.novell.com
Organization: Novell NPD -- Sandy, UT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 23 Jul 1992 16:15:36 GMT
Lines: 65

In article <[e-mail]>, [e-mail] (Chaitanya Nagappa) writes:
|> The  following reply is again posted for a friend, viz, Ravi Ramachandran.
|> -C. Nagappa.
|> ---------------------------------------------------------------------------
|>
|> In article <[e-mail]> [e-mail] (John Foy) writes:
|> >
|> >In article <[e-mail]>, [e-mail] 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.
|> >|>[...]
|> >|>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 need both sides to establish communication/ know it was established -
|> similar to that of a virtual circuit establishment (SYNC, ACK, etc.).

This is kind of questionable; how do you know that the appropriate server gets
all the packets for a particular connection?  Bletch...

|> >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...
|> >
|> "select" enables the process to work wait for an event to occur on one of
|> multiple file descriptors - FIFOs, streams, etc. Unfortunately, not on
|> message queues, semaphores, or any other muliplexed listening posts.

VMS equivalent: SYS$WAITEFLOR()

|> From a fellow netter I had received a possible solution using signals.
|> Unfortunately, there is the problem that multiple signals, before processing
|> it, will be seen as a single signal. Another reply indicated that this
|> was a flaw with standard Unix implementation that device driver writers
|> had to deal with; unfortunately, the solution was propreitary.

I don't really understand the problem; why can't you have two readers on the
same socket?  Are you saying that your reads will not get full packets?  I
can't see a situation where this would occur, unless you are talking about
"packets" for your user level protocol which are fragged, or unless you have
a vmin set to smaller than the packet size you are reading for.  An alternative
complaint could be that select wakes both processes... is this the case?

You need to state, in simple terms, the behaviour you are seeing and the
behaviour you expect to see; your expectations should be in terms of what you
want to do, not in terms of "it would be nice if select()...".  Once that this
is done, I'm sure someone here can help you, if only to tell you it's impossible.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.