STREAMS query

[Steve Glaser]

In article <2864 at sun.uucp> guy at sun.uucp (Guy Harris) writes:

	>> = me
	>  = Guy

>> The main advantages of streams over sockets are:
>> ...
>> 	5.  less wired in knowledge of TCP/IP - potential to support
>> 	    other protocols easier (yeah I know that 4.2 tried to solve
>> 	    this problem, but they got a few things wrong here)
>> ...

>Presumably, 4.3 fixed this to support XNS.  In a streams-based mechanism as
>described above, the routing code used by the IP module could as full of IP
>dependencies as the 4.2 routing code.

I think what Guy is refering to is the crocks in 4.2 where it wan't
general enough about network addresses (like using an int for them...).

Actually, an example of what I had in mind here is the accept sequence
on a passive open.  In 4.2 (TCP/IP) the syscall sequence in the server
looks something like:

	1. socket()
	2. bind()
	3. listen()
	4. accept()

The accept blocks till a connection request is received.  It returns
new file descriptor representing the *open* connection.  If the server
didn't really want to talk to somebody (say it only accepts conections
from specific users), it would have to close the connection.  The
client side has now seen a "connection succeed" followed by a "close
connection".

In the ISO transport layer (ISO TP4), the server has the option of
rejecting the connection *before* the other end has seen its
"connect()" succeed.  In addition, there is some optional "user data"
that gets sent in the connection request and connection accept/reject
packets.

4.2 BSD does not support this cleanly.  Yeah I know you could kludge it
up and have your TP4 protocol module return a file descriptor that is
open as far as the socket layer is concerned, but refuses to work until
you to some magic ioctls to finish the accept (and similarly for
connect requests on the client).

As I understand what AT&T is doing (Summit, not research), they are
just recognizing the fact that putting the protocol state transition
model *exactly* at the system call level is wrong.  They have a simple
message scheme to allow a user program to send a message directly to a
protocol module and use those messages to push the protocol module(s)
through their state machines.

You can easily build a library that gives you the functionality
provided in the 4.2 kernel interface, but you haven't constrained the
system call interface to reflect only those protocols that were around
at the time you designed the syscall interface.

	Steve Glaser
	tektronix!steveg        (till 10/14/85)
	harvard!prime!steveg    (after 10/14/85)