PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (11/10/87)
Date: Sun, 08 Nov 87 23:33:03 est
From: dzoey@terminus.umd.edu
Billy,
I agree with you about the socket interface not being the catchall
networking ... it's not the best, but it is (or should be) consistant.
I agree. Speed is somewhat important here, and designing a new interface
would take time and create holy wars.
As for socket options, I will be glad to feedback on any suggestions for the
minimal set, or propose one when I have more time. I assume we will be going
with 4.3 and not 4.2? One request: leave the linger parameter to SOL_LINGER
as a long (or int). You can't believe how many programs broke when ported
to Ultrix (where is is an structure, two longs: a flag and a second counter)...
Does PCIP even support IP options? I know KA9Q does...
The largest problem I've had with sockets has been in dealing with
protocol specific information. For instance, I find the socket interface
awfully clunky when dealing with IP options and urgent TCP data
could be handled a little more gracefully. But, for no nonsense data
transfers, send and recv work fine.
Urgent data is a bit of a problem, because it requires a signal() (or
sigvec()) facility. This is non-trivial under DOS. Also, it would be nice if
sockets were MS-DOS file handles, and could be inherited by forked/spawned
processes, like inetd and rexecd do... As for select(), it really is quite
handy. It is effectively the only way to implement telnet (sans upcalls),
unless you use ioctl/FIONBIO, which is another can of worms...
I am curious as to what other "standard" networking interfaces look like.
How does Sys5 handle the network with their streams concept? What other
networking interfaces are around?
Streams is even uglier. You probably don't want to mess with it...
What do people want in a network interface?
Too much, but you give them what you can...
-Philipminshall@OPAL.BERKELEY.EDU (11/10/87)
What kind of other network interfaces are there? Well, I think that the "User/TCP Interface" specified in section 3.8 of the TCP specification provides a fairly clean interface, at least for a first cut. I believe that one could, on top of this interface, implement sockets (including the horrible treatment of urgent data which is standard in 4.2, and the default in 4.3 unless SO_OOBINLINE is specified). One possible existence proof of this is that (I believe) the UB smart TCP board presents, essentially, this interface to the PC, and UB has code (a "socket library") which looks like sockets to the application program, and talks to this interface (or something very similar) on the other side. The only thing I *know* that I would like, in addition to this interface, is the ability to get a "TCP-to-User" message when some item of "STATUS" has changed. This can keep an application, trying to implement select(2), from having to keep polling the TCP. (Ah, yes, one needs to know the local IP address sometimes - but that doesn't fall right out of the "socket interface" either.) I agree thoroughly with the sentiments that we don't want to get into the religious wars which would ensue from trying to design a new interface; I agree just as strongly with the sentiment that the "socket interface" is not a standard - most vendors describe their interface as a "socket-style interface". I don't want environments which are "easy to port socket-style code to"; I want environments which are binary compatible. What it really comes down to, I think, is that some sort of effort would need to be funded by some power-that-be. Maybe the ULANA people (who, I believe, underwrote the NETBIOS/TCP effort) would be interested? It's a lot of work, and work isn't free (not even for universities). Greg Minshall
nelson@CLUTX.CLARKSON.EDU (Russell Nelson) (11/10/87)
Urgent data is a bit of a problem, because it requires a signal() (or sigvec()) facility. This is non-trivial under DOS. Also, it would be nice if sockets were MS-DOS file handles, and could be inherited by forked/spawned processes, like inetd and rexecd do... As for select(), it really is quite handy. It is effectively the only way to implement telnet (sans upcalls), unless you use ioctl/FIONBIO, which is another can of worms... If anyone is into a really gross hack, I know how to create device drivers on the fly. Using this scheme, every time the application created a new socket, the underlying Internet driver could create a new device, open it, set it to raw mode, and pass it back to the application. Then all read/writes will get passed to the "device driver" which would write them to the appropriate internal socket, TCP, UDP, or whatever. Like I said, it's a gross hack, but it works under all extant versions of MS-DOG.
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/10/87)
Big problem with device drivers. They only pass a byte at a time across the interface... Drew
nelson@CLUTX.CLARKSON.EDU (Russell Nelson) (11/10/87)
Date: Tue, 10 Nov 87 13:25:03 -0500 (EST) From: Drew Daniel Perkins <ddp+@andrew.cmu.edu> Big problem with device drivers. They only pass a byte at a time across the interface... Not when you put them in raw mode. Raw mode also fixes a problem with MS-DOG 2.0 where it returns a read count of one less than was actually read. :-( -russ
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (11/11/87)
Well, I'm a sick puppy, so let's hear all about your MS-DOG hack. Do you have any text on how this is done? Is it `legitimate' (does any other application do this)? Is it version specific? -Philip
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (11/11/87)
Funding? Did I hear funding? Well, I'm looking for a new paycheck, so why not... You're right about binary compatibility. Being source compatible with the Berkeley man pages isn't enough. When I wrote the FTP S/W sockets library, half (or there abouts) of the calls from our beta sites where problems having to do with VAX ints not being the size of PC ints. If you look at the gethostid(2) call, you will see that it returns an int, which really should be a long, even if they are the same thing on a VAX... This is duplicated many places in the socket interface. So when do we draft this new spec? I'm game... -Philip
nelson@CLUTX.CLARKSON.EDU (Russell Nelson) (11/11/87)
Briefly, since many people might not be interested, the hack goes like this: Open a socket: /* the NUL device is the head of the device chain */ Open the NUL device with an FCB. If (version==2.x) NUL_device_header_ptr = fcb_reserved + 1; else if (version<3.20) NUL_device_header_ptr = fcb_reserved + 2; else NUL_device_header_ptr = (fcb_reserved + 2) + FCB_MAGIC; Find the end of the device chain. Link your device into the device chain. Open the device. Set it to raw mode using IOCTL. /* takes care of a MS-DOG 2.x bug. */ /* also sends entire block of data */ /* to the device. */ return the handle as your socket handle. Close a socket: close the socket handle. unlink the created device from the device chain. There are a few details missing, but that's the gist of it.
bc@halley.UUCP (Bill Crews) (11/17/87)
A couple of people have asked me via e-mail what TLI is, after I suggested
that TLI might be a superior interface to *networks* than sockets or the
interface suggested by the TCP RFC. First, TLI stands for Transport-Level
Interface. This is essentially AT&T's answer to sockets and is the way
networking applications access Streams-based protocol stacks.
One reason it might be better is that it makes no assumptions about the
underlying protocols -- or, I should say, minimal assumptions. For instance,
connection-oriented service, a "byte-stream" mode is supported. Some
underlying protocols may allow preservation of message boundaries and some may
not. The application programmer can maintain portability by refraining from
making that assumption. Nothing in TLI forces that assumption.
I heard a shot taken recently at Streams. I would be interested in hearing
what the complaint is, since the message-passing mechanism in Streams, among
other things, allows protocol layers to be really isolated. This matters to
people who want their applications to run over TCP/IP or UDP/IP or TP4/IP
(different IP) or XNS/IDP (I think that's what it is called) and so on.
I would also be interested to hear if anyone has complaints about TLI's
provision for expedited data.
One significant point here is whether the software interface you are trying to
achieve is intended to be protocol-independent. Although most networking
applications now use sockets, new and upgraded applications will be using TLI
as well. Why not take advantage of this fact and the fact that, with TLI, one
also gets the protocol-independence one needs in these days of OSI, TCP/IP,
and XNS suites AND multiple protocol paths within each suite?
If you need a lower-level interface for speed for nonportable applications,
fine, but please provide also a protocol-independent transport mechanism. I'm
trying to get protocol stack interoperability at levels 5 and 6 as well, but
am always drug back by problems at level 4.
-bc
--
Bill Crews Tandem Computers
Austin, Texas
..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350