home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / internal / 1591 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.6 KB  |  55 lines
  1. Newsgroups: comp.unix.internals
  2. Path: sparky!uunet!caen!zaphod.mps.ohio-state.edu!menudo.uh.edu!nagappa
  3. From: nagappa@menudo.uh.edu (Chaitanya Nagappa)
  4. Subject: Re: Multiple listeners on same socket
  5. Message-ID: <1992Jul23.140202.9816@menudo.uh.edu>
  6. Organization: University of Houston
  7. References: <1992Jul22.034730.12159@menudo.uh.edu> <1992Jul23.084108.22337@rdg.dec.com>
  8. Date: Thu, 23 Jul 1992 14:02:02 GMT
  9. Lines: 44
  10.  
  11. The  following reply is again posted for a friend, viz, Ravi Ramachandran.
  12. -C. Nagappa.
  13. ---------------------------------------------------------------------------
  14.  
  15. In article <1992Jul23.084108.22337@rdg.dec.com> jfoy@narcy.gao.dec.com (John Foy) writes:
  16. >
  17. >In article <1992Jul22.034730.12159@menudo.uh.edu>, nagappa@menudo.uh.edu writes:
  18. >|>==============================================================================
  19. >|>Howdy all,
  20. >|>I need something equivalent to a socket, but that more than one process
  21. >|>can listen on. This is for multiple consumers, and the output from the
  22. >|>server can be picked up by any one of the consumers. In the simplest
  23. >|>scenario, I have two processes doing a "listen" on the same socket,
  24. >|>and only one of these process is trigerred to establish the circuit.
  25. >|>[...]
  26. >|>The problem of statically placing this using standard IPC methods such as
  27. >|>message queues, FIFOs or shared memory is that by the time my processes
  28. >|>get around to receiving the info. (worst case scenario) the call might
  29. >|>have been cleared. So I need a phased communication of the info.
  30. >
  31. >I'm not sure what you mean by "phased communcation..."?
  32. >
  33. I need both sides to establish communication/ know it was established -
  34. similar to that of a virtual circuit establishment (SYNC, ACK, etc.).
  35.  
  36. >I'm not entirely familiar with select etc... (being more of a VMS'r) but have
  37. >you considered semaphores? e.g. the server pool waits on a counting semaphore
  38. >which is incremented by the 'dispatching' process (I think you refer to this
  39. >as the 'spawned' process)...? This way only available servers respond...
  40. >
  41. "select" enables the process to work wait for an event to occur on one of
  42. multiple file descriptors - FIFOs, streams, etc. Unfortunately, not on
  43. message queues, semaphores, or any other muliplexed listening posts.
  44.  
  45. From a fellow netter I had received a possible solution using signals.
  46. Unfortunately, there is the problem that multiple signals, before processing
  47. it, will be seen as a single signal. Another reply indicated that this
  48. was a flaw with standard Unix implementation that device driver writers
  49. had to deal with; unfortunately, the solution was propreitary.
  50.  
  51. >    jf
  52. >
  53. --Ravi.
  54.  
  55.