home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / internal / 1578 < prev    next >
Encoding:
Text File  |  1992-07-21  |  2.2 KB  |  45 lines

  1. Newsgroups: comp.unix.internals
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!nagappa
  3. From: nagappa@menudo.uh.edu (Chaitanya Nagappa)
  4. Subject: Multiple listeners on same socket
  5. Message-ID: <1992Jul22.034730.12159@menudo.uh.edu>
  6. Organization: University of Houston
  7. Date: Wed, 22 Jul 1992 03:47:30 GMT
  8. Lines: 35
  9.  
  10. The following is posted for a friend of mine.
  11. -C. Nagappa.
  12.  
  13. ==============================================================================
  14. Howdy all,
  15. I need something equivalent to a socket, but that more than one process
  16. can listen on. This is for multiple consumers, and the output from the
  17. server can be picked up by any one of the consumers. In the simplest
  18. scenario, I have two processes doing a "listen" on the same socket,
  19. and only one of these process is trigerred to establish the circuit.
  20. Yes, I know neither BSD sockets or TLI can do this. What is then the
  21. alternative? Do I have to create my own virtual device?
  22.  
  23. Message queues & FIFOs are not a viable alternative, as the information
  24. once placed cannot be easily retracted. For those of you who want the
  25. details of what I am trying to do:
  26. I have a machine that has a X.25 board on it. Unfortunately, the Co.
  27. that wrote the drivers for incoming calls on it assumed that the call
  28. can be handled on a one to one basis. I have 10 processes running with
  29. each being able to handle about 12 calls. The processes are event driven
  30. (using select). I thus need the process being spawned by the incoming
  31. call to pass on its logical channel number to any one of my 10 processes.
  32. The problem of statically placing this using standard IPC methods such as
  33. message queues, FIFOs or shared memory is that by the time my processes
  34. get around to receiving the info. (worst case scenario) the call might
  35. have been cleared. So I need a phased communication of the info. I could
  36. assign one port per consumer process, and have my incoming call contact
  37. all of them, so that only the processes that are still consuming (not
  38. reached the limit) can respond, and the first respondant gets the info.
  39. However, this leads to a factorial number of attempts to calls established
  40. (not efficient). I hope someone out there has a solution! If emailing to
  41. this account, please mention my name and I will get a copy of it.
  42.  
  43. Thanks a lot,
  44. --Ravi.
  45.