RE: [colorforth] bulk transfer protocol

[<howerd.oakford@xxxxxxxxxxxx>]

Hi Mark ( and other TCPers ),

My 2 pence worth on TCP :

TCP is general purpose, but in practice uses packets consisting of 512 bytes
of payload plus 20 bytes of header info.
The 512 bytes matches one disk sector on many ( older ) OS's.
The Internet guarantees that packets less than 576 bytes will not be
fragmented by the IP layer, so these packets will arrive complete ( not as
several IP packets ).

Each TCP packet contains a "file offset" value - a 32 bit number which is
incremented for each byte sent, and a count of the nunber of bytes of
payload.
When a TCP packet arrives it is effectively put in the "file" at the "file
offset".
The next ACK sent contains the "file offset" of the "file" being
reconstructed, up to where all required "sectors" have been received. If a
"sector" goes missing, the ACK "file offset" will stick at the end of the
last sector received, and the sender will timeout and send the missing
"sector" again.

The reason for this scheme is that if all goes well there will be at least
two "sectors" in transit before the sender even thinks about whether the
packet was received correctly. This means that the sender can send
continuosly in the hope that it will get a positive ACK eventually. The
alternative would be to wait for an ACK on every packet which would mean one
transit time delay between each packet sent.

The receive window is a 16 bit value ( often 8K ) which tells the sender the
current size of the receiver's buffer.
So, after the connection is established ( parameters such as the window size
are exchanged ) the sender can only send 16 512 byte packets before it knows
that the receiver's buffer is full, unless it receives an ACK which updates
the window size and/or the "file pointer". This is termed flow control, and
is probably not needed these days. It was very important when the computers
had 16K of RAM and a slow hard disk...

Using these two simple techniques allows TCP to run as fast as the link and
receiving computer allow.

Every TCP packet header contains very similar data to the previous one, so a
compression scheme may be used : Van Jacobson.
Support for this ( or not ) is agreed when the connection is established.
Up to sixteen connections are allowed. Two new types of packets are defined
: Uncompressed and compressed Van Jacobson.
Uncompresed VJ packets are very similar to TCP, but their header data is
saved for use by compressed VJ packets.
The Compressed VJ packets send only the differences between this packet and
the last Uncompressed one received on the given connection. The encoding
rules are fiddly - an 8 bit byte marks which of 8 possible fields are to be
changed, and the delta values follow. Since you can specify that you do not
support VJ I think we can safely ignore this...

My own objections to TCP are more to do with the "Berkley Sockets" interface
and the implicit use of files.
TCP forms an interface layer between files/pipes and multitasking OS calls.
The idea is that the program using TCP does not have to be aware of TCP, and
vice versa. I think it would be best if we write a set of TCP words, in
classic Forth style, which can be used to create say a Telnet client. The
TCP for this could be very different to one designed to perform an HTTP GET
function.

I hope that this makes sense, and that I have got it right... ;)

BTW TFTP is a Trivial File Transfer Protocol based on UDP. It deals with
many of the issues discussed in this mailing list.

Regards

Howerd












---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com