Return to BSD News archive
Xref: sserve comp.unix.internals:7611 comp.unix.solaris:21768 comp.unix.sys5.r4:8213 comp.unix.bsd:14720 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.uwa.edu.au!DIALix!haywire.DIALix.oz.au!not-for-mail From: peter@haywire.DIALix.COM (Peter Wemm) Newsgroups: comp.unix.internals,comp.unix.solaris,comp.unix.sys5.r4,comp.unix.bsd Subject: Re: DLPI Vs BSD Sockets Vs Sys V TLI Date: 27 Aug 1994 05:06:35 +0800 Organization: DIALix Services, Perth, Australia. Lines: 61 Sender: peter@haywire.DIALix.COM Distribution: inet Message-ID: <33llgr$cn5$1@haywire.DIALix.COM> References: <33ft3u$mn3@news.tamu.edu> <33iecq$leg@crl2.crl.com> NNTP-Posting-Host: haywire.dialix.com X-Newsreader: NN version 6.5.0 #59 (NOV) cgi@crl.com (Paul Smith) writes: >Amit W Kumar (akumar@cs.tamu.edu) wrote: >: I'm trying to run some tests over our FDDI ring, and am looking to use >: whatever has the least overhead. So, my question is: which of >: DLPI/sockets/TLI would be the most efficient to do this? DLPI seemed >: the logical choice to me, but I read somewhere about it being "a >: bloated montrosity" with way too much overhead. :) Would somebody care >: to shed some light on this? >"Some light" is the following: >1st, get the Prentise Hall books for SVR4.2 on streams and streams drivers. >these docs contain a good over view on Unix Internationl's architectural >view of a streams based protocol stack on SVR4. >2nd, DLPI is the lowest layer on top of the LAN card hardware. Short of >NOT installing the kernel driver for your LAN card, and writting a driver >your self to startup DMA etc to and from the card, there is no closer API >on solaris/SVR4.* to the LAN card than DLPI. Note that device >/dev/lan_card_token is the DLPI stream head that you may open and ioctl() >to using the DLPI commands. >3rd, TLI is the layer 4/ transport layer interface stream API. Functionally >equivalent to Berkeley Sockets API. But the sockets API on SVR4.* is >implimented as a library translation layer into TLI calls. SLOW! Or >more accurately, slower than calling TLI direcly. This is of course >using either TCP or UDP over IP over DLPI. So, DLPI is the fastest, or >closest to the hardware you can get short of writting your own driver... >Yours. Nah. That's ancient history. (mostly..). This is the way I understand it: SVR4.0 version 1.0 was implemented with Wollongong TCP/IP and had a sockets emulation library that called the TLI routines. In SVR4.0 version 2.0, they ripped it out and replaced the tcp/ip part with Lachman TCP and started using Sun's "sockmod" module. BSD-Style sockets in this implementation were built on top of TPI - transport provider interface, as is the TLI stuff. The BSD sockets and TLI gunk were on fairly equal footing. (It just so happens that TPI supports the TLI semantics much better than sockets.) However.. AT&T, in their infinite wisdom, decided to stick with the Wollongong stack in their 3b and starserver series. AT&T SVR4 is quite different to the USL SVR4. (wonderful things like renaming "inetd" to "tlid" and other things resulted. Every so often, somebody posts problems to the starserver mailing list as a result of an "interesting" socket emulation that does not quite obey berkeley semantics). I believe NCR (now AT&T GIS) are in the same boat. And then along came Sun. Somewhere along the way, they've replaced (in Solaris 2.x) the Lachman TCP/IP code with something else. I've heard conflicting opinions on _who_ did the stack: some say it's from Mentat, others say it's a fresh 4.3bsd+ port. If anybody knows the details, I'd love to know for sure.. -Peter