Xref: utzoo comp.unix.wizards:11897 comp.protocols.iso:175
Path: utzoo!attcan!uunet!husc6!bbn!rochester!ritcv!cci632!ccicpg!yarran
From: yarran@ccicpg.UUCP (Yarran A Lu)
Newsgroups: comp.unix.wizards,comp.protocols.iso
Subject: STREAMS: problem of listen connect.ind in module
Keywords: STREAMS, listen, connect indication, module, queue
Message-ID: <33329@ccicpg.UUCP>
Date: 21 Oct 88 18:34:01 GMT
Organization: CCI (Commercial Products Division), Irvine CA
Lines: 20

In implementing connection-oriented protocol module there is a problem when
the next downstream module/driver is also a connection-oriented protocol.
The listening queue which is connected to the next downstream module/driver is 
used to receive connect.indication primitives and seems it is better to be 
always kept in the listening state.  When the module gets the connect.ind
primitive, it responds back to the lower layer module/driver with a connect.
response primitive in order to accept the call.  The problem arises on whether 
the listening module should accept the call on the listening queue or create
a new queue to accept the call.  In the former case, the listening queue will
be changed into data transfer state and no more connect.indication primitives
can be put into the queue anymore, until the user process finally receives the
call and create a second queue to accept the call (by using ioctl I_FDINSERT).
During this period, all the following connect.indications have to be either
queued in the lower layer module/driver or be discarded. In the latter case,
unfortunately, AT&T did not supply any STREAMS function call  for creating
a queue between modules.  Of course, you can probably avoid this case by
implementing it as a mux driver and pre-allocate all the queues. But this  
approach is undocumented and seems violate the original intent of mux driver.

Is there any STREAMS guru or AT&T STREAMS architect knowing the answer?