nick@spider.co.uk (Nick Felisiak) (09/05/90)
In article <2117@rossignol.Princeton.EDU> Tom Reingold writes: > At my job, we are about to write some applications for running over > TCP/IP on Unix hosts. We would like to think ahead with portability in > mind. One day, our code may run on a non-unix host. And if we write > it in sockets, we may run against a version that is built upon and > supports only STREAMS. Or will we? > 1. What implementations are built on STREAMS? There are three that I know of, and probably several that I don't. I'm not trying to be exahustive below! 1. Lachman/Interactive - this originated from Convergent Technology, and is widely used on 386 machines. 2. Wollongong - used by AT&T. 3. Spider - used by Prime, Olivetti (In the UK), etc. > 2. Are they new or old? Spider's was done specifically for streams - i.e the kernel code is not based on BSD! > 3. Are all TCP/IP suites done with sockets nowadays? I think all the UNIX products offer both sockets and TLI. > 4. Is there a reason to consider implementing our code in STREAMS? If it's application level code, this is largely irrelevant. > 5. Currently, our hosts run System V release 3.[23] and have both > libraries. Which is "the way" to go? I discuss my biases below. In article <1990Aug24.220021.10122@murdoch.acc.Virginia.EDU>, Ran Atkinson continues: > The network interfaces specified by the System V Interface Definition > and by the X/Open consortium are based on the STREAMS with TLI (Transport > Level Interface) that were originally developed at AT&T. (What follows may be considered controversial!) TLI is firstly very ISO-oriented, and secondly half a specification. This causes the TCP interface user a number of problems. The ISO-orientation means that certain things which TCP wants to do are just impossible. There is no equvalent to the 'getpeername()' call, for instance. Inetd style servers cannot, therefore, discover where they are being called from (if they care) using TLI as defined. The 'half-a-specification' aspect refers to the lack of a 'standard' for address formats, name services, etc. In the TCP world, I think everyone has gone for the Berkley 'sockaddr' structure as the address structure used in t_bind, etc. Lucky there was a standard already there! I've seen one implementation (can't remember who's) which took a host name and port number as ASCII strings - which is probably more in the spirit of TLI. I never found out if they had put the whole of the resolver library into the kernel, or what they did about specifying the remote address on a connect indication. I have a long list of shortcomings of TLI - mail me if you're interested! > Since the System V socket-library is built on top of STREAMS/TLI, > an application written to use sockets will probably be slower on > a System V system that the same application written using STREAMS/TLI > natively. In general I think that the STREAMS/TLI approach is better > because details of the transport protocol used are appropriately hidden > unlike BSD sockets. Not true. TLI does not provide a super-set of the Socket interface, and so building a compatible socket interface on top of TLI is not possible. We (Spider) have a 'socket library' which uses ioctl calls (in the main) to our TCP driver, which also understands the TLI messages (TPI at that level). I really don't see how details of the transport protocol are hidden by TLI. You still need to code up name to address translation (almost certainly using 'gethostbyname' type calls), and probably implement the TLI counterpart to 'setsocketoptions' differently for each vendor's TCP/TLI that you try to work with, since there is no standard specified for such things as keep-alive, no-delay, IP options, etc. The socket model, on the other hand, provides a de-facto standard for all these things. > Certainly a lot of good software is out there using sockets and I don't > think that the socket library will disappear anytime soon, but for new > software I really think that STREAMS/TLI are a better approach -- > especially if developing for a System V platform. There have already been a few changes to TLI since it first appeared, and I expect there will be more. The socket interface, on the other hand, is pretty stable. I've ported code from BSD systems to Sys-V using our socket interface without any problems in the networking area. It's worth considering that most of our ISO product customers require a socket interface along side TLI as well! The presence of ISO in BSD4.4 will go a long way to establish the 'standard' for this interface. Usual disclaoimers apply. Nick Felisiak nick@spider.co.uk Spider Systems Ltd +44 31 554 9424