davis@groucho.ucar.edu (Glenn P. Davis) (12/04/90)
We are writing a system which will use process to process communication with the processes perhaps residing on different hosts. The emphasis is on portability. My first cut at this uses BSD 4.3 style TCP sockets. My boss is wondering why I wasn't forward looking enough to use didn't use "Transport Level Interface" from System V. (He has been reading the Sun "Network Programming Guide" which contains a warning that "Socket based IPC is no longer the preferred framework for transport level programming...."). My sense is that more systems currently support the BSD socket interface than support TLI or STREAMS. Is this the case? My sense is that this will remain the case for some time, at least on the order of 3 years. Or, at worst case, that the BSD socket interface will still be around for awhile. What about that? Is TLI or Streams in 4.4 BSD? How does 4.4 BSD handle alternate, say OSI, transport? Thank You for your responses. Glenn P. Davis UCAR / Unidata PO Box 3000 3300 Mitchell Lane, Suite 170 Boulder, CO 80307-3000 Boulder, CO 80301 (303) 497 8643
amanda@visix.com (Amanda Walker) (12/04/90)
In article <9389@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes: > We are writing a system which will use process to process communication > with the processes perhaps residing on different hosts. > The emphasis is on portability. > > My first cut at this uses BSD 4.3 style TCP sockets. > My boss is wondering why I wasn't forward looking enough to use > didn't use "Transport Level Interface" from System V. If you're really concerned about portability, you are going to have to do both. My suggestion is to write a higher-level library that provides the functions you need, and hides the underlying mechanism. This way you don't end up with` socket (or TLI) dependencies sprinkled through your code. Which version you start with depends mainly on what machine(s) you are using for your initial development. I would, however, suggest that you read up on TLI before you start writing much code, just so you have enough background knowledge to avoid any major differences in capability (not that I remember any off hand). Amanda Walker Visix Software Inc.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/05/90)
In <9389@ncar.ucar.edu> davis@groucho.ucar.edu (Glenn P. Davis) writes: >(He has been reading the Sun "Network Programming Guide" which >contains a warning that "Socket based IPC is no longer the preferred >framework for transport level programming...."). This comes from the AT&T SVR4 manuals and represents a corporate "party line" rather than any practising software engineer's opinion. Considering that 99% of existing implementations of UNIX provide no support for TLI, using it at this point would result is extermely nonportable code. SVR4 is still in its infancy. Except for a few bugs, it supports the socket interface. Since no existing software uses AT&T's TLI, which is very new and untested, your best bet is to (a) use the socket interface but (b) make sure your code doesn't trigger the socket-related bugs in SVR4, which are documented in the AT&T manuals. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
chad@qip.UUCP (Chad R. Larson) (12/06/90)
In article <2766@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: +--------------- | Considering that 99% of existing implementations of UNIX provide no | ^^^^^ | support for TLI, using it at this point would result is extermely | nonportable code. +--------------- 73.4% of the people who quote statistics make them up. At our site, we have four different vendors for Unix and three of them support TLI. That makes it 25% if you are counting types. If you count population of machines, its more like 30 to 5 (or 16%) and the 5 are scheduled for upgrade. If you are concerned with portability (and the original poster was), you can't ignore TLI and streams. It is the socket interface that will be going away (but not for a *long* time...). -crl -- Chad R. Larson ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020 (602) 870-3330 "I read the news today, oh boy!" -- John Lennon
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (12/07/90)
In article <9389@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes: >...[about TLI or Streams vs. Sockets]... It would be really keen if someone could and would say something numeric about the relative speed of TLI (ne XLI or whatever--any version more recent than the one delivered to AT&T in 1986) compared to sockets (any version from 4.2 to Reno and beyond). Yes, this is my quarterly request for time-to-port-ttcp-from-sockets-to-tli and/or performance-of-ttcp-over-tli numbers. (TTCP is the most common TCP benchmark. Most commonly used as well as most commonly abused and perverted to generate marketing numbers, and most commonly enhanced to do things the enhancer considers important. Look for the authorative source on brl.mil and more or less true copies many other places, including sgi.com.) Vernon Schryver Silicon Graphics vjs@sgi.com
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <9389@ncar.ucar.edu> davis@groucho.ucar.edu (Glenn P. Davis) writes:
[ use sockets or TLI? ]
You could ftp pub/flat/inet-socketstream from stealth.acf.nyu.edu to get
the archive of the last discussion we had on the topic.
---Danljm@TWG.COM (01/03/91)
> >If you are concerned with portability (and the original poster was), you >can't ignore TLI and streams. It is the socket interface that will be >going away (but not for a *long* time...). > I usually find the most useful way to explain the relationship of TLI and sockets is to consider TLI the 'native' transport interface for UNIX and sockets is more of a cross-platform API. Thus, the native interface for UNIX is TLI which is different from the native interface for the Macintosh, MacTCP, which is different from the native interface(s) for DOS, FTP Software's or our's or whatever, which is different from the native interface on VMS, and so on. The tradeoff is usually quite simple. On all the platforms, the native interface offers unique advantages to the developer of system specific applications in terms of memory usage, performance, functionality or perhaps all three. However, a sockets API is available on all of these platforms. So, if you are absolutely sure that your application will only run on one of them, or if your application absolutely requires the improved functionallity only present in the native interface, then use it. Otherwise, use the sockets API as it will ease the port of your application to different platforms (or even same platform/different vendor in the DOS and OS/2 cases). enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com
dls@mentor.cc.purdue.edu (David L Stevens) (01/03/91)
Oh, please! Please put "System V" or "AT&T" somewhere around that "UNIX". Let's not forget that Berkeley UNIX, using the socket interface they invented, had TCP/IP support while AT&T still proudly proclaimed that they had "networking" support, meaning UUCP. For the only UNIX that's been a real player in internetworking for the last, what, 8 years?, sockets are the "native" interface and TLI support is something you add so you can deal with the latecomers. In a TCP/IP news group, which one has really earned the right to be called "UNIX," unadorned? :-) -- +-DLS (dls@mentor.cc.purdue.edu)
scum@virtech.uucp (Steven C. Monroe) (01/03/91)
ljm@TWG.COM writes: >> >>If you are concerned with portability (and the original poster was), you >>can't ignore TLI and streams. It is the socket interface that will be >>going away (but not for a *long* time...). >> >I usually find the most useful way to explain the relationship of TLI >and sockets is to consider TLI the 'native' transport interface for >UNIX and sockets is more of a cross-platform API. In my one rather feeble attempt to deal with TLI showed me some that there are some deficiencies (IMHO) that need to be addressed. This project was attempted because the vendor supplied more than one other vendors Ethernet TCP/IP package. The TLI provides NO support functions to map a system target (UUCP?, Ethernet?, SLIP?) with an addressing facility (X.500 will supply this?). So I ended up having to know about what the "real" bottom layer was in order to build the sockaddr structures to get the call made. >So, if you are absolutely sure that your application will only >run on one of them, or if your application absolutely requires the improved >functionallity only present in the native interface, then use it. >Otherwise, use the sockets API as it will ease the port of your application >to different platforms (or even same platform/different vendor in the DOS >and OS/2 cases). As far as I'm concerned, I'll use sockets until all of the facilities that I need are available. I don't have the time or resources to build my own version of X.500, especially when they exist is the socket library. >enjoy, >leo j mclaughlin iii >The Wollongong Group >ljm@twg.com -- Steven C. Monroe (703)430-9247 Virtual Technologies, Inc., uunet!virtech!scum 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/12/91)
In <9101021513.aa02786@Mercury.TWG.COM> ljm@TWG.COM writes:
...consider TLI the 'native' transport interface for
UNIX and sockets is more of a cross-platform API.
As others have pointed out, you should have said System V, not UNIX.
The tradeoff is usually quite simple. On all the platforms, the
native interface offers unique advantages to the developer of
system specific applications in terms of memory usage,
performance, functionality or perhaps all three.
This is where I get puzzled. I have read the comparison of sockets vs
TLI in Stevens's book, and I've read AT&T's documentation. All I can
find is that TLI has some bugs (e.g. failed writes not correctly
reported). I don't see what TLI does so much better than sockets. Is
TLI more than another manifestation of the NIH syndrome? What are its
performance, functionality, and memory usage benefits?
--
History never | Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
becomes obsolete. | UUCP: oliveb!cirrusl!dhesi