RE: [colorforth] bulk transfer protocol

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Wed, 5 May 2004 howerd.oakford@xxxxxxxxxxxx wrote:

> Hi Mark ( and other TCPers ),

Hello Howerd,

>
> My 2 pence worth on TCP :

[ snip ]

> 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.

This is not quite correct. The sender can only send a windows worth of
segments (to use the TCP terminology). But it apears you correct the
assertation below.

> The
> alternative would be to wait for an ACK on every packet which would mean one
> transit time delay between each packet sent.

There are many alternatives to the TCP way. I've presented one, lacking of
course congestion control which I have not fully researched. I have since
done a search for "bulk transfer protocol", it appears RDP, and NETBLT
were alternatives to TCP considered at one time.

>
> 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.

This is not true. TCP will have a delay when the window is used up.
Additionaly a lost segment will block flow, the TCP will wait for a
timeout to retransmit. Also, a lost ACKnowledge will block flow until a
retrasmitted ACKnowledge finds its way to the sender, this involves more
timeouts and probably more retransmissions on the sender side. In practice
the performance of TCP is not so simple to analyze or optimize.

>
> Every TCP packet header contains very similar data to the previous one, so a
> compression scheme may be used : Van Jacobson.

[ snip ]

> Since you can specify that you do not
> support VJ I think we can safely ignore this...

I think this is mainly for serial links.

>
> 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.

This is what I am currently thinking. For example, a TCP implementation
should not contain the Nagle algorithm, however an interactive application
that uses TCP should. Perhaps a TCP can be simpler if its customized for
the application.

>
> 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.
>

From the TFTP document:

 Any transfer begins with a request to read or write a file, which also
serves to request a connection. If the server grants the request, the
connection is opened and the file is sent in fixed length blocks of 512
bytes. Each data packet contains one block of data, and must be
acknowledged by an acknowledgment packet before the next packet can be
sent. A data packet of less than 512 bytes signals termination of a
transfer. If a packet gets lost in the network, the intended recipient
will timeout and may retransmit his last packet (which may be data or an
acknowledgment), thus causing the sender of the lost packet to retransmit
that lost packet. The sender has to keep just one packet on hand for
retransmission, since the lock step acknowledgment guarantees that all
older packets have been received. Notice that both machines involved in a
transfer are considered senders and receivers. One sends data and receives
acknowledgments, the other sends acknowledgments and receives data.


> Regards
>
> Howerd

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