streams 1-to-many multiplexor driver
Jeremy Harris
jgh at unisoft.UUCP
Tue Jul 4 03:54:33 AEST 1989
In article <1116 at adds.newyork.NCR.COM> tanya at adds.newyork.NCR.COM (Tanya Katz) writes:
>
[ asking how to write a bottom-multiplexing streams driver ]
>
> I am writing a streams multiplexer driver that monitors
>input from several (many) ttys, packets the data, and routes the packeted
>input to one single process. On output, the M_DATA field will
>be encoded with the port number, sent through the multiplexor, and
>routed to the proper tty.
>
>A central issue [..] is minimizing the use of file descriptors
[..]
>the streams data structures
>design seem to indicate that we must open a separate minor multiplexor
>device for each tty stream & link these in separately
>in order to properly initialize the lower write queue of the linkblk
>structure.
No problem here; you only need the one stream into the top of the multiplexer.
Every time you link a new tty stream into the bottom of the mux, you
(with your mux hat on) get told the lower write queue to use for writing
to that stream. All you have to do is remember that in association
with some criteria for routing through the multiplexer (in your case
this can probably be the l_index value); it doesn't matter that all
the I_LINKs are issued from a single top stream.
You mentioned using an array for remembering these things. How about
a linked list using dynamically allocated structures? Use allocb()
for the allocator. You then haven't the same hard limit on number
of channels in use.
Since the data travelling the multiplexed stream carries control
information as well as pure data, consider using M_PROTO messages
and putmsg()/getmsg() rather than M_DATA. Any naive process which
tries to read()/write() by some mistake then finds out the error
of its ways rapidly.
Hope this helps, and happy Streaming.
Jeremy
PS: my credentials: internet protocols as streams modules; about
eight modules and drivers, two of which were bottom-multiplexers.
Took about two man-years. And it's far more maintainable
than 4.3 code.
-
Jeremy Harris UniSoft Ltd. 8/9 Hayne St, London EC1A 9HH. England
jgh at root44.co.uk (briefly on loan to UniSoft Corp.)
More information about the Comp.sys.att
mailing list