fraser@mdivax1.uucp (Cameron Fraser) (04/08/89)
We build message switching systems to link our radio data networks with various type of host computers. Upto now the systems have been based on SYSV message queues because they offer us the best combination of portability (ATT/DEC/COMPAQ/etc.) and speed. However the shortcomings particularly the inability to do the equivalent of poll() or select() on multiple queues really hinders design. We looked at streams but backed away because of portability concerns and are now looking at a simple pseudo-device driver. I'd appreciate hearing from anyone that has tackled this problem already or who is interested in working on it (for instance demonstrating portability to their own environment). ------------------------------------------------------------------- Cameron Fraser uunet!van-bc!mdivax1!fraser Product Development (604) 277-1511 Mobile Data International ENVOY 100: mdi.fraser Richmond, B.C. CANADA (800) 663-8279 (US only) ------------------------------------------------------------------- -- ------------------------------------------------------------------- Cameron Fraser uunet!van-bc!mdivax1!fraser Product Development (604) 277-1511 Mobile Data International ENVOY 100: mdi.fraser
ka@june.cs.washington.edu (Kenneth Almquist) (04/16/89)
fraser@mdivax1.uucp (Cameron Fraser) writes: > > We build message switching systems to link our radio data networks > with various type of host computers. ... The inability to do the > equivalent of poll() or select() on multiple queues really hinders > design. It may limit the design choices available to you, but I have a hard time imagining a problem for which a select() call is actually needed. Take your current design (using select) and each place where the code does a select on a bunch of message queues, replace these queues with a single queue. Add an extra field to the messages to let you know which of the queues in the original design each message was destined for, if necessary. If there are places where you want to do a select on only a subset of the queues that have been merged into a single queue, either uses the message type field to get only the messages you want, or else read all messages and buffer the unwanted ones inside the reader process for later processing. If you merge two queues that had different access permissions in the original design, you can still get statistical security by writing a key manager that creates and distributes passwords. In conclusion, you are better off sticking with the existing message facilities rather than extending them with a select operation--if the existing facilities are adequate for what you want to do. Without knowing more about your application I can't say for *sure* that the existing facilities are adequate, but I would be quite surprised if they weren't. Kenneth Almquist