dougm@violet.isc.COM ("Doug McCallum") (08/01/87)
In reply to your message of 31 Jul 87 14:21:22 GMT ------- >It seems that AT&T's TLI primitives are not very different from the >Berkeley socket calls. For example: poll == select; t_open == socket; >t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen; >t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown... Actually, t_bind == (bind+listen) (t_listen+t_accept) == accept t_connect == connect t_rcv/t_snd == read/write (or send/recv) t_rcvudata/t_sndudata == recvfrom/sendto The mappings aren't quite exact, but close enough. With the names being so similar, expecially t_listen and t_accept, it is easy to assume they work the same way. >Did NIH have something to do with the design of TLI? Probably a little NIH and a little of trying to generalize a little further. There are some good ideas, too bad there are some bad ones as well. >Actually the real question is: >If I have an application that communicates with other processes using >fairly vanilla socket calls, couldn't I just implement the socket calls >for the System V port using TLI calls or at least encapsulate the Unix >calls within my own primitives? Or am I missing some basic incompatibility? Almost. Without doing some work with which modules are present in the stream you might have some minor problems. If you stay with SOCK_STREAM type usage, you can do pretty well by having the socket emulation library set the STREAM up to have the read/write interface once the connection is established. The SOCK_DGRAM type sockets would be more work since address information won't be available if you do a read. In fact the read will fail if there is address information (in a control portion of a message) and you haven't setup the read/write interface. The recv*/send* emulation could deal with it though. The main problem is that while sockets preserve file descriptor semantics, TLI doesn't. You have to use TLI calls unless you make provisions to use the read/write interface. You can't have both at the same time. >Oh yes, another question: >Are there any System V equivalents for the Berkeley Network library functions, >such as gethostent and inet_addr, and files such as /etc/hosts and >/etc/services? I found no mention in the Network Programmer's Guide or >Release Notes. Do I have to pay extra for them? Nope.
dougm@violet.ico.isc.COM ("Doug McCallum") (03/12/88)
In reply to your message of Thu, 10 Mar 88 22:21:49 PST ------- > falsehoods. Sun uses standard chips supplied by both Intel and AMD for > our ethernet interfaces, and while they may be the fastest > implementations available on the market, they are completely within > Ethernet specifications. Next time you hear one of these stories from Just having controllers made with standard chips does not ensure that they are within specification. I don't remember the details of the LANCE chip, but the Intel 82586 can be configured to violate just about every parameter you might think of. The interpacket spacing is one such parameter. The parameterization makes it useful for implementing different speed networks (like Starlan) with the same chips. So, even though Sun's products are made with standard parts doesn't guarantee that someone hasn't changed parameters to something non-standard.
jas@MONK.PROTEON.COM (John A. Shriver) (03/14/88)
I quick look with adb at SunOS 3.4 reveals that Sun is initializing the Intel 82586 Ethernet chip per Ethernet specifications for interfame spacing. The instruction: _iedefaultconf+0x5a: movb #0x60,a5@(0xb) is moving an interfame spacing of 96 bits (9.6 microseconds) to the interfame spacing (offset 0xb) field in the Configure command block for the 82586. Confirm this for yourself on your Sun. They are not cheating. There are simply Ethernet boards that crash trying to do address compares at full speed, and there are host implementations (DECnet-VAX) that assume that the Ethernet interface will always send packets than they can generate them. These implementations have Ethernet-related bugs--the Sun does not. The Sun proves to be a good tool for finding these bugs. Enough said?
dougm@ICO.ISC.COM ("Doug McCallum") (02/04/90)
In reply to your message of 3 Feb 90 00:22:02 GMT ------- > In article <1990Feb2.154728.17877@ico.isc.com>, dougm@ico.isc.com (Doug McCallum) writes: > > In article <1990Feb1.052144.27172@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > > ... > > AT&T's TCP/IP is based on the Wollongong port and not the Lachman port. > In which release ? SVR4 is definitely the Convergent/Lachmann port. SVR3. SVR4 is only barely out the door and is only available to a small handful of people. THe discussion was about currently shipping 386 based UNIX systems.
dougm@ICO.ISC.COM ("Doug McCallum") (08/29/90)
In reply to your message of 29 August 1990 0643-PDT (Wednesday) ------- > Anybody know what tirdwr does? Gather/scatter packets to satisfy > the read/write size argument? Some oob handling? All tirdwr does is get rid of the protocol part of the TLI (actually TPI) messages. Read/write can only deal with what are called M_DATA messages. The protocol between TLI and TPI (Transport Provider Interface) has another message block type (M_PROTO) in front of the data. It also interprets disconnects. Anything else, like an expedited data message (T_EXDATA_IND) is a fatal error. > ps. Is there anyway to get a list of all the modules pushed onto > a stream. I_LOOK only lists the top most module. Not in V.3. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com
jrallen@devildog.att.com (Jon Allen) (08/31/90)
In article <9008291444.AA15182@violet.ICO.ISC.COM> dougm@ICO.ISC.COM ("Doug McCallum") writes: ... >> ps. Is there anyway to get a list of all the modules pushed onto >> a stream. I_LOOK only lists the top most module. > >Not in V.3. Actually it is not quite that bad. You should have an idea of all the possible modules that COULD be on a given stream (not many). It is then trivial to write a little program which uses I_FIND to see if the module is on the stream. You could then query for modules by using a command such as: ./ifind tirdwr < /dev/WHATEVER, or make it a subroutine in your program. I use this method to determine what modules are on a given tty stream. -Jon
dougm@ICO.ISC.COM ("Doug McCallum") (09/03/90)
In reply to your message of Fri, 31 Aug 90 09:34:13 +0100 ------- > do any of TLI, NLI or DLI contain something with more functionality > than sockets - like a standard management interface, or a standard > packet filter or traceer interface - and i dont mean ioctl and nit > like vaguaries TLI has been discussed to death. It is similar to sockets and has adherents and detractors like sockets do. 4.4BSD sockets pretty much fix the deficiencies that TLI tried to address. NLI and DLI don't exist with those names. There is NPI and DLPI. They are interfaces between STREAMS modules and don't really have any relationship to sockets or anything like that. They could have programming interfaces defined for them but there currently aren't any. Of course, since they are just STREAMS messages, a user level program can access the interfaces. To summarize what NPI (Network Provider Interface) and DLPI (Data Link Provider Interface) are: NPI: Provides a common set of primitives that are based on the OSI service primitives for network services. The intent is to have a common set of primitives to allow a transport provider to be able to communicate with a network service provider. While not really necessary, it does provide a way to cleanly separate the network provider from the other parts of the stack and to allow multiple providers. One possibility is to have CONS and CLNS network providers for OSI under a single stack. In reality, it is just a nice way to do something similar to RAW sockets but then be able to link the network STREAM under a provider module and construct a new stack without having to modify any part of the network provider driver. NPI provides for connection primitives as well as connectionless. DLPI: This is the STREAMS interface to data link device drivers. While similar to NIT and other mechanisms for gaining access to the device driver level, it really is just the mechanism for a network service provider to communicate with the device driver. A STREAM can be opened and bound to some service access point (Ethertype, 802.2 LSAP, whatever) and then be linked under a network provider module. It is possible to use it a user level to implement things like RARP or other application that uses the data link level directly. The V.4 DLPI also includes primitives for connection oriented protocols such as 802.2 Class 2 Type 2 LLC. > if not, i suggest its just more noiseware to make unix less useful, > designed by manufacturers running scared from real open systems and > shareware... TLI may have been that. It does seem to smack of NIH. NPI and DLPI developed to meet a different need - that of getting vendors to write drivers that would work with other vendors protocol stacks. Since STREAMS isn't a protocol or driver implementation itself and is only the framework to develop protocols and drivers, there needed to be a consistant interface between the various types of modules. NPI and DLPI are intended to do that. The BSD way doesn't fit the STREAMS model very well. Besides, DLPI at least, is far more flexible. The drivers don't have to be modified to allow a third party vendor's protocol stack take advantage of them. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com