ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/06/87)
I've now talked with 3 of the major groups implementing TSR TCP/IP drivers for the PC. All of them already have working TSR's in alpha/beta test, and all have developed different interfaces. None of them are very willing to abandon their interface in order to pursue a standard. So being realistic, I really don't think we can have a standard. However, all is not lost. Two of the three have already begun work on a BSD socket interface, and the third group is interested in doing so. It is my personal belief, and I think most others agree, that if they can use a BSD socket interface they will, for purposes of portability. CITI is developing a socket interface for the MAC. Most will have it for the PC. Of course UNIX already has it. Some people are concerned about it's performance, however I think that portability far outweighs the small performance hit. Therefore, I am proposing that we should develop a standard for a BSD socket interface on PC's. The standard should probably be interrupt based. Everyone is quite familiar with them. I've convinced myself and atleast one of the far call advocates that the small performance improvement of far calls vs. interrupts will get lost compared to everything else. Other issues are exactly which BSD calls should be supported, which interrupt, should it be dynamic, etc. I would also like to propose that we schedule a BOF at the TCP/IP conference in December. Comments? Drew
jac@UMD5.UMD.EDU ("Joseph A. Cimmino Jr.") (11/06/87)
Yes, a BOF in December would be a great time to discuss the issues. Re a common socket interface: Are you supposing TSR'd socket support? Only then can we discuss an interrupt interface, however having the entire stack (hardware to sockets) loaded might be considered unreasonable memory overhead to some. I'd like to hear more about what options for socket support are envisioned. Along those lines, maybe we could also discuss LIM 4.0 support. /jac
earle@MAHENDO.JPL.NASA.GOV (Greg Earle) (11/06/87)
Hasn't the Sun PC-NFS Toolkit 1.0 beaten everyone to the punch? Full implementation of the socket interface, etc. ... When/where is the TCP/IP conference? I'd like to go ... On a different note, is anyone familiar with the programmatic differences between the MICOM/Interlan NI5010 board and the NI5210? We just got the source for the NCSA PC-Telnet 2.1 with NI5210 support; alas, we have NI5010's. From a friend who has 3Com boards, and can run the ready-made .EXE that came with it, it's quite a hummer ... Perhaps Drew or someone could point me at an appropriate place in the PC/IP NI5010 code to start comparing ... Greg Earle earle@mahendo.JPL.NASA.GOV S(*CENSORED*)t earle%mahendo@jpl-elroy.ARPA [aka:] Rockwell International earle%mahendo@elroy.JPL.NASA.GOV Seal Beach, CA ...!cit-vax!elroy!jplgodo!mahendo!earle
minshall@OPAL.BERKELEY.EDU (11/06/87)
Drew,
If what you are suggesting is a TSR which maps "standardized"
socket calls into "vendor X's TCP calls", then I think this is minimally
acceptable ("minimally" because of my feeling that for high performance one
needs something better than sockets). It would certainly be a wonderful
step over what we have.
What we (applications types, and systems administrators) need
is the ability to have one .EXE file for, say, telnet which will execute
on "all" our PC's. Right now we can do this, but at the expense of
restricting our PC's to all run one vendor's TCP.
So, if your proposal will allow us to do this, hurray!
We can, I suppose, address the performance issues with some
follow-on work.
A BOF at the TCP/IP conference sounds good. For those who
haven't heard, the "TCP/IP Interoperability Conference" will be
held December 1-4, 1987, at the Hyatt Regency Crystal City in
Arlington, VA. Contact Advanced Computing Environments at
(408)996-2042 for info.
Gregddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/07/87)
What's "LIM 4.0"? Yes, I am proposing loading the whole stack. Compared to TCP/UDP/IP/device support, the socket stuff shouldn't be that much additional overhead. Drew
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/07/87)
Greg, A TSR for "standardized" socket calls is exactly what I am suggesting. This would allow exactly what you desire for compatibility. Someone could buy FTP Softwares PC/TCP or IBM PC/IP or SU's PC/IP or SUN's NFS or whatever. They could base their decision on whatever they wanted, price, features, performance, etc. However, if they wrote to the socket interface, they could still run it on any PC no matter who's PC/IP is on it. People who really want high performance could write to their vendors "fast" interface, trading off portability. Drew
backman@interlan.UUCP (Larry Backman) (11/07/87)
In article <wVYGO8y00UoJytM1ca@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: >I've now talked with 3 of the major groups implementing TSR TCP/IP drivers >for the PC. All of them already have working TSR's in alpha/beta test, and > >However, all is not lost. Two of the three have already begun work on a BSD >socket interface, and the third group is interested in doing so. It is my > >Therefore, I am proposing that we should develop a standard for a BSD socket >interface on PC's. The standard should probably be interrupt based. > >I would also like to propose that we schedule a BOF at the TCP/IP conference >in December. Comments? > Count me in for a BOF meeting. Micom - Interlan is currently beta- testing a Netware/TCP gateway that has a BSD 4.2 Socket Interface. The Socket interface will become a product very soon. We also are working on other DOS products based on the same socket interface. We've had to do some tricky things in DOS to make sockets work, other vendors probably have solved the same problems. anyways, realistically, a socket standard under DOS may be a nice idea in concept, I would settle for a series of guidelines for least common denominator functionality. These would include the basics: socket bind connect accept read write readv writev readmessage sendmessage .... you get the idea... Additional functionality could be provided via supersets signal select and even more functionality could be provided by DOS tailored calls async_read async_write .....etc. Now a socket program (TELNET for instance) can be quickly ported to the Least common denominator functions, and later enhanced by changing base calls such as READ to tailored calls such as READ_ASYNC. This allows a quick port followed by as much tuning as needed to make a nice DOS socket program. Anyways, as I said count me in for the BOF meeting. Larry Backman
backman@interlan.UUCP (Larry Backman) (11/07/87)
In article <wVYUVoy00UoJytM2Nu@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: >What's "LIM 4.0"? Yes, I am proposing loading the whole stack. Compared to >TCP/UDP/IP/device support, the socket stuff shouldn't be that much >additional overhead. > LIM 4.0 == Lotus Intel Microsoft Enhanced Memory Specification Version 4.0. This is a means by which executable code can be placed up in extended memory, and page down into the DOS 640K window when that code is executing. Now TSR's stay up high except when invoked. Very clever, but oh it looks tricky.... larry Backman
geoff@eagle_snax.UUCP ( R.H. coast near the top) (11/08/87)
In article <wVYGO8y00UoJytM1ca@andrew.cmu.edu>, ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: > Therefore, I am proposing that we should develop a standard for a BSD socket > interface on PC's. The standard should probably be interrupt based. > Everyone is quite familiar with them. I've convinced myself and atleast one > of the far call advocates that the small performance improvement of far > calls vs. interrupts will get lost compared to everything else. Other > issues are exactly which BSD calls should be supported, which interrupt, > should it be dynamic, etc. Actually there is another subtle problem: do you want to implement true BSD compatibility and allow reads, writes, ioctls, etc. on socket descriptors? If so, you need another chunk of software in the form of a socket device driver which plays by DOS's rules. We've done this for PC-NFS, but it was by no means easy: consider all of the potential control-break scenarios, for example. > > I would also like to propose that we schedule a BOF at the TCP/IP conference > in December. Comments? > > Drew Sounds great to me. See you there. -- 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]
egisin@orchid.UUCP (11/09/87)
In article <8711061732.AA04324@opal.berkeley.edu>, minshall@OPAL.BERKELEY.EDU writes: > If what you are suggesting is a TSR which maps "standardized" > socket calls into "vendor X's TCP calls", then I think this is minimally > acceptable ("minimally" because of my feeling that for high performance one > needs something better than sockets). It would certainly be a wonderful > step over what we have. > Do you have some figures for a high performance low-level interface versus a low performance socket interface on an AT-class machine? The only difference I can think of in the implementation of these two interfaces is that a socket interface would probably copy data between the user process and network "process", and a low-level one probably would not. That amounts to <10% overhead for a tcp that does 1M/sec. (and if an AT can't do 1M/sec, then you should be looking at the hardware and overall implementation, not the interface).
minshall@VIOLET.BERKELEY.EDU (11/11/87)
No, I don't have any performance figures. However, I've programmed the UB board both "directly" and via their socket library. The "direct" method certainly optimized *PC* processing cycles. The standard Unix-style mechanism for performing I/O (and I'm much of a Unix bigot) is to say "do this", and not get control back until "this" is done. On a write, this means you don't get control back until your output buffer has been stashed away somewhere. On a read, this means you don't get control pack until your buffer has been filled up. This is really non-optimal. Double-bufferring is a fairly old concept, and fairly powerful. Allowing the user to say "start up this I/O, and let me know when it is complete" is a good performance boost. It is not only useful for saving copies (though I don't think one should knock the performance gains there), but also because it (can) allow one to get out of the style of "give me data; process data; output data". One of the benefits of the MIT "upcall" mechanism is that the program is driven by the data, rather than the other way around (note that I'm not all that sure that the "upcall" mechanism is the greatest mode of operation; however, I'd like to provide an underlying mechanism on top of which "everything" could be built). (There *is* some philosophy here; I am prepared to neither defend nor make it more concrete at this time. I have been spending a lot of time, though, in the past six months or so wondering how to move data around inside a machine much faster than we currently do.) TOTALLY separate topic. In a message recently, someone mentioned that select(2) was neat, and (paraphrasing) you could hardly build telnet without it. This is very true under Unix; however, I certainly hope that we are convinced that we are trying to do *networking*, and not Unix-emulation. In other words, the mechanisms we want to provide would work for networking connections, but NOT for the terminal (which is a large part of what makes select(2) so useful for telnet - it works for the network AND the terminal). Most PC applications that need to check the terminal will use select(2) in "poll" mode, and use kbhit() (or whatever) to talk with the keyboard. (I, by the way, at one time wrote my own socket-emulation library, and included emulation of TTY ioctls and select. I believe that to have been a VERY wrong thing to have done (and hereby repent).) Greg
bc@halley.UUCP (Bill Crews) (11/13/87)
In article <8711061732.AA04324@opal.berkeley.edu> minshall@OPAL.BERKELEY.EDU writes: >Drew, > If what you are suggesting is a TSR which maps "standardized" >socket calls into "vendor X's TCP calls", then I think this is minimally >acceptable ("minimally" because of my feeling that for high performance one >needs something better than sockets). > >Greg It is unclear to me the performance disadvantage of a socket interface. I think sockets and TLI are fairly reasonable transport interfaces. Since sockets are not yet entrenched on PCs, I would prefer TLI for a de facto standard. The conversion from sockets to TLI is not great, and a couple of years from now, we may be glad we did. I propose a TLI TSR interface with both TLI and socket *libraries* that map to the TLI interface. Aren't Microsoft and 3Com working on reaching some kind of standard like this based on TLI? Whatever is done along TSR and LIM 4.0 lines, a dynalink interface for OS/2 should be conformant to the same standard. -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350
minshall@VIOLET.BERKELEY.EDU (11/14/87)
Why aren't sockets the best thing in the world? Well, for one thing,
they can cause more copying of data than one would like. This is true
because the semantics of "send" is that, when the send returns, the "sent"
buffer must be immediately usable by the application (so, that physical buffer
can't be used as a queueing space for "not-yet-sent" TCP data. Also,
the "receive" operation does not pass control of the "receive" buffer
to the transport layer beyond the duration of the "receive" call itself
(so, that buffer can't be used to copy in data later received on
the connection).
The above are the performance reasons. There is also a semantics
problem: sockets have socket-semantics, TCP has TCP-semantics. The mapping
between the two sets of semantics is fairly good, but not ideal (if
even complete). I would like a TCP interface with TCP semantics. I would
(like Bill Crews, and everyone else) like to see a sockets library. My
socket library, however, would map the sockets semantics to TCP semantics.
(By the way, absolutely no one, I predict, is going to want the
*semantics* of the "out-of-band" data from 4.2/4.3. It is unreliable
for many applications; ie: it can drop data bytes from the TCP stream.
But, this is part of the "socket standard". Oh, sigh, I'm just grumbling...)
In Bill Crews message (<301@halley.UUCP>), he mentions a TLI.
I would like more information on this interface.
Greg Minshallddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (11/16/87)
What is "TLI"? Drew
bc@halley.UUCP (Bill Crews) (11/17/87)
My remarks about TLI and in qualified support of sockets in earlier postings
were based on the assumption that Drew had a real reason to want to interface
to the network at a network level, rather than at a (lean, mean) protocol-
specific level. I would prefer that TLI get cast in concrete rather than
sockets, though I still applaud support of sockets for the purpose of enabling
straight-forward ports of networking applications written to that interface
under Berkeley networking Unix.
But the mini world (including Unix and OS/2) is not the DOS world. In the
DOS world, cheating the system is still (and will continue to be) the norm,
and in such an environment, a lower-layer and higher-performance interface
should also be supported. Notice the word "also". Not all Telnet
implementations will be updating the time-of-day clock on the 25th line
between keyboard and display events, so a generic network interface would ALSO
pay off. Your select (or SysV poll) might be useful under Windows 2.0, eh?
An interface that might be worth looking at is 3Com's 3L Link Level Library,
which provides "shared buffers", which is what Greg wants, but which also
provides enough protocol-independence at least to allow the same interface to
be used for access to either their Ethernet or their Token Ring boards. Of
course, this is a link-level interface, but what the hey?
-bc
--
Bill Crews Tandem Computers
Austin, Texas
..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350bc@halley.UUCP (Bill Crews) (11/20/87)
In article <8711140117.AA08165@violet.berkeley.edu> minshall@VIOLET.BERKELEY.EDU writes: > Why aren't sockets the best thing in the world? Well, for one thing, >they can cause more copying of data than one would like. This is true >because the semantics of "send" is that, when the send returns, the "sent" >buffer must be immediately usable by the application (so, that physical buffer >can't be used as a queueing space for "not-yet-sent" TCP data. Also, >the "receive" operation does not pass control of the "receive" buffer >to the transport layer beyond the duration of the "receive" call itself >(so, that buffer can't be used to copy in data later received on >the connection). For PCs in real mode, this is a characteristic that one is stuck with, leaving one with the choice between layer isolation and performance, to that degree. With most hardware these days, one can diddle the page tables to "poof" the data into kernel space without moving it. But the PC lives on. Sigh. > The above are the performance reasons. There is also a semantics >problem: sockets have socket-semantics, TCP has TCP-semantics. The mapping >between the two sets of semantics is fairly good, but not ideal (if >even complete). I would like a TCP interface with TCP semantics. I would >(like Bill Crews, and everyone else) like to see a sockets library. My >socket library, however, would map the sockets semantics to TCP semantics. Uh, what does that mean? What else would one do? You aren't proposing contaminating the socket interface with knowledge of the underlying transport, are you? Do you want a TCP interface or a transport-protocol-independent interface, like sockets or TLI? > [...] > In Bill Crews message (<301@halley.UUCP>), he mentions a TLI. >I would like more information on this interface. OK. TLI is a part of Unix System V.3 network services. I would imagine that most V.3 manual sets will contain TLI documentation. I've been using the Unix System V Network Programmer's Guide for the AT&T 3Bs. Other very interesting reading can be found in the Unix System V STREAMS Programmer's Guide and the STREAMS Primer. Now, TLI doesn't imply STREAMS and STREAMS doesn't imply TLI. They are both good ideas, though, and are both implemented in V.3. Happy reading. > Greg Minshall -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350
narayan@lll-ati.arpa (Narayan Moharram) (11/21/87)
In article <304@halley.UUCP> bc@halley.UUCP (Bill Crews) writes: > > >Uh, what does that mean? What else would one do? You aren't proposing >contaminating the socket interface with knowledge of the underlying transport, >are you? Do you want a TCP interface or a transport-protocol-independent >interface, like sockets or TLI? > >> [...] > >> In Bill Crews message (<301@halley.UUCP>), he mentions a TLI. >>I would like more information on this interface. > >OK. TLI is a part of Unix System V.3 network services. I would imagine that >most V.3 manual sets will contain TLI documentation. I've been using >the Unix System V Network Programmer's Guide for the AT&T 3Bs. Other very >interesting reading can be found in the Unix System V STREAMS Programmer's >Guide and the STREAMS Primer. Now, TLI doesn't imply STREAMS and STREAMS >doesn't imply TLI. They are both good ideas, though, and are both implemented >in V.3. If you don't have an AT&T lisence (sp?) you can get a identical interface from XOPEN. They call it XTI, and it is essentially the same thing.
karn@faline.UUCP (11/21/87)
I've been following the discussion about standard programming interfaces to transport protocols on the PC, but I'm puzzled. The ability to support multiple concurrent applications was an absolute design criteria in the KA9Q Internet Protocol package. Since MS-DOS by itself is little more than a glorified bootstrap loader, I had little choice but to combine all of the protocols and applications into a single MS-DOS program (net.exe) which essentially takes over the machine and performs a crude form of multitasking internally. (You *can* run other things alongside net.exe by using DoubleDos or Desqview, but there's no inter-process communication). I see little hope of establishing a standard application/transport interface on the PC until we can trash MS-DOS in favor of a "grownup" operating system. I'm not willing to sacrifice concurrent applications. I'd like to come to the TCP/IP Interoperability conference, but I already agreed to go to another conference to talk about...yes, TCP/IP. :-) Phil
gts@violet.berkeley.edu (Greg Small) (11/22/87)
= From: karn@faline.bellcore.com (Phil R. Karn) = Date: 21 Nov 87 02:39:19 GMT = Organization: Bell Communications Research, Inc = = I see little hope of establishing a standard application/transport = interface on the PC until we can trash MS-DOS in favor of a "grownup" = operating system. I'm not willing to sacrifice concurrent applications. Actually, multiple network applications can easily run on Netbios or TCP-IP because they can be called by a resident network driver when activity occurs. I have not been following this discussion closely but I surmise that this is what "up call" means (Netbios calles them "post interrupts"). Actually "grown up" operating systems are too bulky and inefficient for the many, many applications that are ideal for a PC class workstation. Just because DOS/BIOS is a small, highly accessable operating system doesn't mean that is cannot participate in concurrent network applications. Gregory T Small (415)642-5979 Personal Computer Networking & Communications gts@jade.Berkeley.EDU Data Communications and Networking Group ucbvax!jade!gts Computer Facilities and Communications SPGGTS@UCBCMSA.BITNET 216 Evans Hall CFC University of California, Berkeley, Ca 94720
nelson@CLUTX.CLARKSON.EDU (Russell Nelson) (11/22/87)
I have several points: o Phil is incorrect: MS-DOG is not just a bootstrap loader, but it's a filesystem driver as well. This is no advantage as the filesystem happens to be poorly thought out. o Greg is incorrect: A "grown up" operating system need not be large and inefficient. Imagine where we would be today if Microsoft had had the sense to provide USABLE device drivers for the screen, keyboard, and serial ports. We would be able to run protected mode programs with no great overhead. But that's besides the point. The problem with Phil's scheme of providing everything in one program is that the user has no control over what services are provided. If you want your tcp/ip to provide different services, like NNTP, or Unix Talk, you have to recompile NET. If you have an unsupported interface, you have to recompile NET. The solution is to split NET apart into seperately loaded modules, which talk to one-another via a shared software interrupt. That is what the discussion is about, and that's my current project.
bc@halley.UUCP (Bill Crews) (11/30/87)
In article <1563@faline.bellcore.com> karn@faline.bellcore.com (Phil R. Karn) writes: >I've been following the discussion about standard programming interfaces >to transport protocols on the PC, but I'm puzzled. > >The ability to support multiple concurrent applications was an absolute >design criteria in the KA9Q Internet Protocol package. Since MS-DOS by >itself is little more than a glorified bootstrap loader, I had little >choice but to combine all of the protocols and applications into a >single MS-DOS program (net.exe) which essentially takes over the machine >and performs a crude form of multitasking internally. (You *can* run >other things alongside net.exe by using DoubleDos or Desqview, but >there's no inter-process communication). Now *I*'m puzzled. If (a) DOS is normally used in a single-tasking mode and (b) with DoubleDOS or DesqView, you don't get interprocess communication, then how do you figure that a self-contained net.exe supports "multiple concurrent applications"? Are all the applications built into the net.exe (yuck!)? The normal DOS-ish way of doing this is to provide an interface across a software interrupt -- i.e., TSR. But somehow this is what you are arguing *against*? >I see little hope of establishing a standard application/transport >interface on the PC until we can trash MS-DOS in favor of a "grownup" >operating system. I'm not willing to sacrifice concurrent applications. What do programming interfaces and application portability across them have to do with the fact that DOS is single-tasking? This seem to me to be independent. >I'd like to come to the TCP/IP Interoperability conference, but I already >agreed to go to another conference to talk about...yes, TCP/IP. :-) Darn, Karn, I was hoping to see you there, and to talk with you about KA9Q. -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350