Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!zodiac!joyce!hercules!fernwood!asylum!romkey
From: romkey@asylum.SF.CA.US (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Super-Dumb Transport Protocol?
Message-ID: <2484@asylum.SF.CA.US>
Date: 13 Jun 89 06:09:13 GMT
References: <93400023@p.cs.uiuc.edu>
Reply-To: romkey@asylum.UUCP (John Romkey,The Asylum)
Organization: The Asylum; Belmont, CA
Lines: 30

In article <93400023@p.cs.uiuc.edu> zweig@p.cs.uiuc.edu writes:
>That is, a protocol that just involves a
>client sending a reqest which, if received by the server, generates a bunch of
>IP datagrams in response (maybe with a terribly naive checksum/retransmit
>of lost/damaged packets mechanism).

Sounds like TFTP to me, just add in the acknowledgements.

>  FTP has far too much baggage -- sitting as it does on top of TCP -- and
>TFTP is close, but still sits on top of UDP.

I've done this several times, so I'm not just hypothesizing here.  If
you've already got an IP, UDP is *trivial*. It adds some demultiplexing
and checksums. It has an 8 byte header. It almost does nothing. IP proper
is *much* more complicated.

The real complexity is in dealing with timeout and retransmission.
You'll find that you'll implement it primarily dealing with a certain
speed of network (serial lines or ethernet or FDDI) and then other
people will come along and run it over a speed at the opposite end of
the spectrum and it won't work so well, so you'll tinker with the
algorithms, and other people will come along and run it on a congested
overloaded network like the ARPANET (well, former-ARPANET) and you'll
need to tinker some more. There's a lot of stuff out there to look at
already to learn about these algorithms, especially Van Jacobsen's
work, but that's where a lot of the complexity comes in.
-- 
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"We had some good machines/But they don't work no more" - Shriekback