gnu@hoptoad.uucp (John Gilmore) (11/23/87)
Throughout the discussion of sockets -vs- TLI, I am getting the persistent
impression that the TLI people think sockets are somehow "TCP/IP specific"
while TLI is "general".
Berkeley sockets are in regular use with at least three major protocol
suites (TCP/IP, Unix domain, and XNS).
I can't say that there are no dependencies, but the major ones are gone.
Note that 4.3BSD sockets were slightly more general than 4.2BSD's, since
XNS had been ported to the system in between.
Another posting said that TLI allows both byte-stream and message-oriented
protocols, implying that this was a feature sockets lack. It ain't so --
sockets can do it too.
I don't know the difference between streams and TLI, though someone
said they are independent, but here's my uneducated complaints about both:
* TLI only exists because of AT&T's "Not Invented Here" attitude, and I
hate to help people who do that.
* The "select" or "poll" call is essential in providing easy, low overhead
access to several network connections or devices or files. For
example, in a telnet (remote login) program, the program should wait
until either a new packet of data comes in, or until a key is hit.
Select was implemented throughout the system -- it works on any kind of
file descriptor. "Poll" only works on streams, not on pipes, files, or
devices like serial ports, requiring ugly kludges for simple stuff like
telnet. And they could have called it "select" since it does the same
thing, but NIH reared its ugly head again.
* I have heard that the multiple protocol levels in a streams implementation
require copying of the data many times as it passes up and down the stream
stack. (Dennis Ritchie's original streams for V8 unix didn't do that, but
the Sys V folks reimplemented it and botched it.)
For me the choice is clear. There's a bunch of public domain software
out that uses the socket interface, and while I could waste my time rewriting
it so AT&T can play NIH, why bother?
For you-all, I don't know if the choice is clear. Best would be to
consult somebody smart who has worked with both. I know Guy Harris (sun!guy)
has done some work with streams; if he can't intelligently contrast
streams/TLI versus sockets, he probably knows who can.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvanianarayan@lll-ati.arpa (Narayan Moharram) (11/23/87)
Each operating system (SV.3 and 4.x BSD) has its own idea of async I/O capabilities. So the question is not select/poll, but what benefits does sockets have over TLI or vice versa. 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. This is not quite as bad as the fact that using TLI you cannot do scattered I/O which is essential for networking protocols. Sockets has a sendmsg /recvmsg capabilty whereby various layers can build thier own headers, in non contiguous buffers, and pass it down to the transport layer. This proves to be a big expense in the TLI mechanism as a lot of copying has to be done (or preknowledge of the next layers headers is necessary). If anyone is interested I can post a paper that was done comparing the two interfaces in various categories.
mark@applix.UUCP (Mark Fox) (11/25/87)
In article <3373@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >For me the choice is clear. There's a bunch of public domain software >out that uses the socket interface, and while I could waste my time rewriting >it so AT&T can play NIH, why bother? I agree. Sounds like somebody with access to both BSD & SVR3 would be performing a great service by implementing a "sockets on top of STREAMS" library and releasing it into the public domain or otherwise make it readily available. I know that The Wollongong Group has already implemented such a library for System V and is selling it (for big bucks?) thereby demonstrating the feasibility of this approach. Any takers? -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: {ames,rutgers}!harvard!m2c!applix!mark
dlnash@ut-emx.UUCP (Donald L. Nash) (11/25/87)
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
BECKER@HUMBER.BITNET.UUCP (11/27/87)
I for one would be interested to read about a detailed comparison between TLI and Berkely sockets. Cheers, B. Becker Humber College Etobicoke, Ont.
larry@pdn.UUCP (11/30/87)
In article <21851@lll-tis.arpa> narayan@lll-ati.arpa (Narayan Moharram) writes: >If anyone is interested I can post a paper that was done comparing >the two interfaces in various categories. Please do, or send e-mail. Thanks, Larry Swift UUCP: {gatech,codas,ucf-cs}!usfvax2!pdn!larry Paradyne Corp., LF-207 Phone: (813) 530-8605 P. O. Box 2826 I refuse to have a battle of wits Largo, FL, 34649-9981 with an unarmed person.