Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!ut-sally!ut-ngp!ut-emx!dlnash
From: dlnash@ut-emx.UUCP (Donald L. Nash)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: In this corner -- sockets!   In that corner -- TLI & streams!
Message-ID: <210@ut-emx.UUCP>
Date: Wed, 25-Nov-87 13:35:59 EST
Article-I.D.: ut-emx.210
Posted: Wed Nov 25 13:35:59 1987
Date-Received: Sun, 29-Nov-87 11:40:20 EST
References: <283548.871111.PAP4@AI.AI.MIT.EDU> <302@halley.UUCP> <21851@lll-tis.arpa>
Organization: The University of Texas at Austin, Austin, Texas
Lines: 50

In article <21851@lll-tis.arpa>, narayan@lll-ati.arpa (Narayan Moharram) writes:
> One of the biggest defects in sockets is the fact that connections
> are accepted by the underlying protocol without giving the user
> a chance to reject an incoming connection request.

When DEC came out with DECnet-DOS, the programming interface for it was
based on the socket model.  However, the DECnet protocols allow the
user to reject the connection if he sees fit.  In order to graft this
into the socket interface, DEC came up with some rather interesting
setsockopt() and getsockopt() options.  It is possible to set a socket
to what is called deferred acceptance mode.  When this is done, a call
to accept() returns without completing the connection.  The user can
then look at who is on the other end, examine any optional connect data
which may have been sent (more on that later), and then decide whether
to accept the connection or reject it.  The final acceptance or
rejection is done with setsockopt(). 

The optional connect data I mentioned is set with another setsockopt()
call and is sent when a process attempts a connect().  It is read at the
other end with a getsockopt() call.  Optional connect data is also sent
when a deferred connection is finally accepted.  Optional connect data
can be up to 16 bytes long. 

Access control information can also be sent in this manner, but only by
a user process, (i.e. in response to a connect() call only).  Access
control info is similar to optional connect data, except that it is
designed specifically to send a user name, password, and account number. 
Each of these can be 40 characters long. 

There is also optional disconnect data which is sent when a socket is
closed (by either end) or when a deferred connection is rejected (by a
server).  As with optional connect data, it is set on one end with
setsockopt(), received on the other end with getsockopt(), and can be up
to 16 bytes long. 

I know that this is comp.protocols.tcp-ip.ibmpc, not c.p.decnet.ibmpc,
but since we're talking about sockets in general here, I thought this
would be of interest.  The point I'm trying to make is that two of the
major complaints against sockets, blindly accepting connections and not
allowing connect/disconnect data, have been solved, by one vendor
anyway.  I don't know much about TLI, so I can't comment on its
deficiencies.

				Don Nash

UUCP:    ...!{ihnp4, allegra, seismo!ut-sally}!ut-emx!dlnash
ARPA:    dlnash@emx.CC.UTEXAS.EDU              ^^|^^^
                ^^^^^^^^^^^^^^^^^----------------|-- note new address
BITNET:	 CCEU001@UTADNX, DLNASH@UTADNX
TEXNET:  UTADNX::CCEU001, UTADNX::DLNASH