BRACKENRIDGE@C.ISI.EDU (Billy) (11/09/87)
I have wanted to respond to several subjects, but have been busy. I just finished a major piece of software this afternoon. So with the help of a bottle of Joseph Phelps 1981 Zinfandel, I have time to drop a few pearls of wisdom on the net. BOF AT TCP/IP INTEROPERABILITY CONFERENCE: John Romkey will be leading a BOF on PCs and Macs at the Washington DC TCP/IP interoperability conference the first week of December. I guess this covers PC/IP and all the other variations. I am sure Phil Karn will be there as will be many from that and other camps. It should be an exciting meeting. As many of us found last year, the sessions are interesting but the real business takes place in the halls. Dan Lynch, who runs this conference, knows his technology and combines that with a great sense of showmanship. His conferences are a lot of fun. John's address is: ROMKEY@XX.LCS.MIT.EDU (617)868-4878 in case you are new to this list. If you are a player in TCP/IP networking you should be at this conference. I don't have the mailing address and phone but contact LYNCH@ISI.EDU if you need registration information. [Dan Lynch would shamelessly bribe me to plug his conference, but didn't have to. -wab] STANDARD LOW LEVEL INTERFACE: I favor a standard hardware interface. I am working for a company called IPT. (Until this month Lutsky Baird). One of our unannounced products is an Ethernet card for the AT style bus. It is based on the AMD 7990 chip set. This is the same chip set used in the SUN 4. I have looked at all the Ethernet chips and think this looks the best on paper. As this chip set allows multiple ethernet addresses per board, a driver could easily multiplex between several client processes running the same protocol family. My first task is to write drivers and give them away to anybody who wants them. I will start with the university distributed PC/IP products and spread to any commercial products that will take my free code. This task would be much easier if there were a standard interface. If we can just get the Phil Karn and the university supported TCP/IP products to adopt a common standard, industry will have to recognize this as a significant installed base. We shouldn't give up on this idea until we have at least tried to reach a consensus at the December conference. Granted 3Comm, Novell, and Microsoft will ignore us as but they are devoted to policies of proprietary networking anyway. They are not going to participate in a standard "socket interface" any more than they will participate in any other standards. It is a false argument to say that because commercial companies won't accept a low level standard we should give up the effort and standardize at the sockets level. I don't think many commercial companies are interested in providing telnet, nfs, ftp, and utility level products. There just isn't much perceived added value. Commercial companies that use IP/TCP use it in things like CAD/CAM or office automation. The networking is hidden. A company can't make a living distributing utilities when the amateur radio and university communities are distributing the same code for free. Of course IBM can always sell anything, and they remain the exception. They can sell code everybody else is giving away for free and make the buyer believe he is one step ahead of his competition. Have I missed something? I want a standard "Raw Packet" interface to the net or the illusion of a "Raw Packet" interface. I want to be able to run IP packets while some other vendor is running some other protocol suite. Sometimes I am not too sure what people are talking about as this discussion rolls past my screen. STANDARD "SOCKETS" IS A MYTH: This Holy Grail is like "Standard Unix" or "Standard C". These are wonderful things to strive for. These are IDEALS. It is very important to have ideals, but some of us have to make systems work today or next week. I have looked at BSD Unix, FTP Software Inc., and Network Research sockets interfaces. They are pretty close and conversion between all of them is not outside the possibility of an experienced C programmer. The semantics of all these interfaces are subtly and maddeningly different but the syntax is close enough to keep a standards committee busy spinning wheels as long as the funding holds out. Both FTP and Network Research provide substantial manuals for their sockets interface. Both begin their manuals with a suggestion that the reader should have a complete set of Berkeley Unix documentation and that these manuals should be considered a supplement to that documentation. If there were a standard sockets interface, they wouldn't have to write manuals. I just finished converting an application from Network Research's sockets style interface to FTP Software's Version 2.0 interface. I have FTP's sockets interface, but it was easier to convert to their standard DOS interface than to a sockets interface. Their DOS interface is much better thought out than the Berkeley sockets interface. Frequently I think of Unix as the "Programmers Continued Employment Act". It seems to me that the purpose of Berkeley Unix is to make sure Berkeley graduates (and drop outs) have regular employment. It is a lot like letting lawyers into legislatures. They just write laws designed to make work for more lawyers. How many of you have actually made a "select" call to a sockets package? It doesn't count if you just copied some application written for Berkeley Unix. I mean: Have you designed a package from scratch and put a select call in your main loop? Did you just look at the manual and say "What an elegant design?" Did you get that same sense of awe at the nature of the universe when you first began to understand quantum electrodynamics? Did it match the thrill in high school of writing Feyneman diagrams in the girls locker room? If you liked select you will love ioctl! The Berkeley sockets interface is to computer networking as the phlogistin theory is to thermodynamics, or Ptolemy's mechanics was to astrophysics. The phlogistin theory works (almost) and the Greeks were able to predict tides based on Ptolemy's model of celestial mechanics. Similarly we are able to do networking using the Berkeley sockets interface, but that doesn't mean we should forever enshrine it as the only way to do networking. The sockets interface is a grubby, inconsistent, inelegant way of doing networking. If we are going to agree on a higher level standard we can do better than the sockets interface. Billy Brackenridge IPT Inc. 23801 Calabasas Road, Suite 2011 Calabasas, CA 91302 (818)347-7791 -------
dzoey@TERMINUS.UMD.EDU (11/09/87)
Billy,
I agree with you about the socket interface not being the catchall networking.
However, it does have the advantage that it is a pseudo-standard and that
applications written to BSD sockets should port fairly quickly to other
socket interfaces. Plus, there's already a large software base of
applications written to the socket interface. Like most standards,
it's not the best, but it is (or should be) consistant. I would like
to see some comment from the net on which socket options the PC socket
standard should support. This seems to be an area of some
inconsistancy among socket interfaces.
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.
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?
What do people want in a network interface?
Curiously
Joe Herman
Univ. of Md. PC/IP
P.S. I have written applications from scratch (copying from BSD is a no-no)
using select(). It's something you get used to fairly quickly.geoff@eagle_snax.UUCP ( R.H. coast near the top) (11/10/87)
In article <8711082123.aa13795@Louie.UDEL.EDU>, BRACKENRIDGE@C.ISI.EDU (Billy) writes: > > STANDARD "SOCKETS" IS A MYTH: > This is like saying "standard SNA is a myth". Standard SNA is whatever IBM says it is. To date, standard sockets are whatever Berkeley says they are. > > Both FTP and Network Research provide substantial manuals for their > sockets interface. Both begin their manuals with a suggestion that > the reader should have a complete set of Berkeley Unix documentation > and that these manuals should be considered a supplement to that > documentation. If there were a standard sockets interface, they > wouldn't have to write manuals. That is, if there were any decent books generally available on how to program network applications with sockets. The whole subject gets 42 pages in the current SunOS docubox, which is scarcely adequate (I don't count the "man" pages). For the PC-NFS Toolkit we came up with a book which not only DOESN'T suggest you read the Berkeley Unix documentation but has become a popular reference for some of the Unix hackers in-house. In large measure this whole problem has arisen because IBM/Microsoft spurned the whole notion of standard language bindings for DOS. Since none of us enjoy tweaking segregs in indosx calls (I hope!), we went ahead and imported what was most familiar. Guess what: it isn't a perfect fit. This shouldn't be a surprise. Had there been a standardized C language binding to NETBIOS, we'd probably have chosen to build on that, extending it as little as possible to provide adequate access to the Internet suite.. If you really don't like sockets, the answer may be to skip DOS and move straight on to OS/2..... |-) -- Geoff Arnold, Sun Microsystems | "What is appropriate for the master is not SPD at ECD (home of PC-NFS) | appropriate for the novice. You must UUCP:{ihnp4,decwrl...}!sun!garnold | understand Tao before transcending struc- ARPA:garnold@sun.com | ture." [The Tao of Programming, p.39]