BRACKENRIDGE%USC-ISIB@sri-unix.UUCP (01/23/84)
From: Billy <BRACKENRIDGE@USC-ISIB>
I hope you get a wide range of responses to your query and would be
interested to see them. As I am including a copy to INFO-IBMPC I
will try to confine my answers to IP/TCP as it applies to the PC
class of machine.
1) Do any LANs currently support TCP/IP (base or broadband)?
You are confusing hardware and software here. The IP and TCP
specifications say nothing about the physical medium on which the
signals travel. For example the MIT IP/TCP package for the IBM-PC
was originaly developed to run on a high speed RS232 connection but
has been adapted to run on the 3Comm Ethernet and a Proteon ring
net.
Our Ethernet at ISI currently carries Xerox PUP and NS, MIT CHAOS,
and DARPA IP ptotocols simultaneously on the same physical cable.
We also have several different hardware LANs that run IP and are
connected through gateways to the ARPANET or WideBand net.
2) If a LAN supports TCP/IP, does any micro hooked to it (as a server,
not just a terminal) have to support the high-powered packages
like FTP, TN, MM, etc???
No. PCs are best when they devote all of their resources to a
single task. For example, I am working on a server that runs on a
PC which will allow a process running on a second computer to send
voice mail. The PC will dial the user's telephone digitize and
compress speech and FTP the user process a file to be sent as voice
mail. No timesharing system could possibly handle the real time
requirements of this task. The system is cost effective precisely
because the machine doesn't have to try to do all possible tasks.
If you have enough special purpose machines combined with a few
general purpose time sharing systems on a LAN a wide range of
computing needs can be accomidated.
3) Does anybody realistically expect a 5MHz 8088 in a single-tasking
environment to handle this kind of comm?
Granted the ROM BIOS busy wait disk I/O in the IBM-PC makes it
terribly difficult to get decent throughput on any network
application which needs to access a a file, but using a simpler
protocol won't solve this problem. In fact the 3Comm Etherlink
software is very slow as it doesn't even overlap file I/O with net
I/O.
I have long advocated that having no process structure in DOS is
superior to having a bad process structure enforced by the
operating system. I expect my concept of a bad process structure is
different from that of your typical business user. Clearly I
wouldn't want whoever wrote PRINT under DOS 2.0 adding generalized
tasking to DOS 3.0. Those applications that need asynchronous
processing typically implement it themselvs.
Again the MIT IP/TCP code stands as an existance proof that IP/TCP
can run very rapidly on a PC. An Ethernet telnet connection appears
to be faster than a direct 9600 baud connection, and cross country
file transfers compare favorably to those on Tops-20.
IP/TCP implementations can be done very efficiently on PCs because
the entire protocol need not be implemented. A great deal of time
and effort is spent on Tops-20 converting host names to IP
addresses. PC implementations rely on external name servers thereby
saving thousands of bytes of code and table space. Similarly on a
timesharing system the network code must handle all possible
options and conditions on multiple connections simultaneously. On a
PC one can compile a specific version of TCP for a telnet
application and a different TCP for a file transfer application.
The code will be faster and leaner than the generalized case.
It seems to me that LANs are just beginning to
be offered with the kind of support software
that makes the idea attractive to the public.
The EtherNet (at least 3Com's implementation)
is advertised to support shared-resource
capability, mail, and other utilities that
bring the paperless office idea almost into
grasp. Forcing the TCP/IP issue, when the
military is the only one using it, puts us
even further behind the general industry.
Commercial operations notably Apollo, Xerox, Wang, and IBM all have
made great strides in networking and resource sharing. They have
the distinct advantage that you can pay your money and get
reasonable delivery, but none of these systems can talk to each
other and none are any simpler than IP/TCP.
If you want commercial LAN you might consider PCnet from Orchid
Technology or the Corvus LAN. These systems are fine for remote
disk servers and simple exchange of messages in a single office
environment. One step up are Sytek, and Interlan who make boxes
which will use a LAN to provide a 9600 baud RS232 to RS232
connection. These systems are great if all you want is point to
point connection and don't want to string dozens of cables.
Those of us in a university environment do have an advantage over
you in the military. We have captive slave labor. John Romkey was a
sophomore when he wrote the MIT IP/TCP. You have to buy it from a
vendor, and by the time your random defense contractor gets through
with it, the taxpayers will be out millions. In the past it has
been unattractive for free market vendors to sell IP/TCP as most
users are in universities who won't pay for it. Perhaps some of the
commercial sites who recieve INFO-IBMPC can help you out.
-------