STREAMS query

[BostonU SysMgr]

>steveg at hammer.UUCP (Steve Glaser) writes
>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".
>....4.2 BSD does not support this cleanly.

The description seems fine but could someone clarify exactly what the
objection is here, with a little more than 'does not support this cleanly'.

Is this a religious issue? If a client connects to a server and the server
wishes to reject on the basis of some info about the remote side, what is
the harm of just tossing the remote side with a shutdown() or close(),
(the other side will get offended at its rude treatment?)

Or is the real issue here that there is no way to securely determine the
USER associated with the client process? If so, I think that is orthogonal
to whether you have to accept() to find out. It's a desireable feature that
can be layered into applications (consider FTP and TELNET for example.)
I think it's semantics, if TP4 is passing that much info it may as well be
open, although standardizing rejections analagous to <errno.h> could be
an advantage in a few situations (might prevent re-tries, see SMTP for
a model of this, fatal, temporary etc rejections.)

In fact, errno.h probably covers just about everything one might want
to say, a few could be added with little harm (we are not *yet* threatening
errno's 2^32 address space! :-) I presume that even in heterogenous nets
most systems on the net support the notion of an integer, so the idea is
portable, adapting to SMTP's format of "errno string<CR><LF>" should be
a fine way to explain to the other side why they are getting 86'd.

	-Barry Shein, Boston University