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