\begin{Howard Lowndes}
> Well, setting TCP_NODELAY in telnet certainly improved things and got rid
> of the 200 ms delay between packets, but I still have a problem in that
> the packets are still going:
> 
> DATA1 -> ACK1 -> DATA2 -> ACK2 ...
> 
> only now the delay is only the length of the circuit latency, which is
> still occasionally causing a problem at the far end.
> 
> My understanding of TCP is that there is the ability to window packets up
> to the window byte limit so that in effect I could have:
> 
> DATA1 -> DATA2 -> ACK1 -> ACK2 ...
> 
> So why is this not happening, or am I misunderstanding here?

what you want is a nagle algorithm ;)

tcp will send whatever was given to it in a single write(2) as soon as
possible. the linux telnet client that you are using must be doing
something like:

 while((c = getchar()) != EOF)
   write(socket, &c, 1);    /* yes, i know c is really an int */

so only single characters are ever written.

if you want to combine the writes on your end, you either need to turn
on nagle (will not *always* combine them they way you want - as you
know) or hack the telnet code to write more than one character at
once.

(TCP_CORK is another way of combining the writes. but i didn't want to
explain that here. see tcp(7). note that "this option cannot be
combined with TCP_NODELAY".)


just keep in mind that its your telnet *servers* that aren't behaving
correctly. to expect sequential key presses to always arrive in the
same packet is pretty unreasonable, given all the things that could
happen along the way.

-- 
 - Gus


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Reply via email to