STREAMS: problem of listen connect.ind in module
Hwa Jin Bae
bae at unisoft.UUCP
Mon Oct 31 09:27:08 AEST 1988
Yarran A Lu's question was:
"......
After step 3, if there is another (N-1)connect.indication PDU arrives at
module Y, there will be no upstream queue in listening state to take the
(N-1)connect.indication primitive. One may suggest that the new stream
created after step 6 may be used to replace the old stream. But there is
no guaranty that after the (N-1)layer connection is established, when the (N)
layer connect.indication will come (sometime a connection is always
maintained alive and can be reused again by the upper layer). The ideal
solution, I think, is that the module should have the same ability, like
the user process has, to create a new queue when it accepts the lower layer
connect.indication. However, there is no STREAMS functions provided by
AT&T to manipulate the queues.
....."
This is a good point. However, you don't need a STREAMS function to solve
this problem. What's needed is some extra data structure and code within
module X to take care of the multiple connections. Usually when
implementing TCP, a pool of TCB's and sockets are allocated in the beginning.
The number of connections that a socket is willing to accept is recorded
in socket data structure when the user makes a 'listen()' call. Then
module X is sent a T_BIND_REQ message with CONIND_number field equal to
that number. With an extra function (call it "listen_one_at_a_time()")
that will go through TCB's and make up a new TCB (which has a pointer
to the socket queue; we are talking about a socket as implemented as
a STREAM head here) and change the state of this TCB to T_WCON_IND.
That is, instead of one-to-one correspondence between socket and TCB,
you can utilize the same queue (allocated to a socket) for multiple
TCB's which may be in various states.
/hjb
--
----------- "I am no Jack Kennedy." ------------------------------
Hwa Jin Bae bae at tis.llnl.gov (Internet)
UniSoft bae at unisoft.UniSoft (smail uucp)
Emeryville, CA ...!uunet!unisoft!bae (plain uucp)
More information about the Comp.unix.wizards
mailing list