Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!zweig
From: zweig@p.cs.uiuc.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Super-Dumb Transport Protocol?
Message-ID: <93400024@p.cs.uiuc.edu>
Date: 14 Jun 89 19:17:00 GMT
References: <93400023@p.cs.uiuc.edu>
Lines: 24
Nf-ID: #R:p.cs.uiuc.edu:93400023:p.cs.uiuc.edu:93400024:000:1422
Nf-From: p.cs.uiuc.edu!zweig    Jun 14 14:17:00 1989


  Thanks to all who pointed out how simple IP/UDP/TFTP can be (I got lots of
e-mail). One can make a dumb IP with a naive view of the network (say, a RARP
server plus a gateway somewhere that will accept any packets I dump onto the
local net that are for nonlocal hosts), a 100-line implementation of UDP and
a TFTP responder. Boink!
  What I _didn't_ want was routing/runtime support above what a really dumb
operating system (MS-DOS, Mac-OS...) could provide/a limited number of
simultaneous connections. The only thing I object to in TFTP is the stop-and-
wait aspect of the protocol -- thoroughly evil on a high-speed, high-latency
connection.
  While I agree it's a waste of time to reinvent the wheel, and that nobody
will be able to speak a new (slightly different) protocol, this seems like
a terribly simple wheel (so not too much time wasted) and, well, nobody spoke
NFS much more than five years ago, either....
  The reason I'm interested in a super-dumb protocol is that a server could
easily have the disk- and net-bandwidth to barf files out to hundreds or
thousands of users simultaneously, but if it has to do anything much more
complicated than just fetch a sector and transmit it (trick: calculate the
checksums when you put the archived file on disk -- no snarftime math!) over
the network, the bottleneck will be at the CPU/Memory interface where it
doesn't belong.

-Johnny Still-scratching-my-head