--
Howard.
______________________________________________________
LANNet Computing Associates <http://www.lannet.com.au>
On Sun, 12 Nov 2000, Angus Lees wrote:
> what you want is a nagle algorithm ;)
I originally had Nagle enabled in telnet and was getting 200 ms delays
between outgoing packets. I then compiled in TCP_NODELAY and the delay
was reduced to the duration of the network latency.
> 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.
I have to question this theory. A single press of a function key in the
VT100 emulation generates at least 3 transmitable characters. Eg, the Up
Arrow generates <ESC>[A
In around 90% of the times these 3 characters will be transmitted in the
one data packet (that is what tcpdump/tcpshow shows), but around 10% of
the time the <ESC> gets sent in one packet and the client waits for that
packet to be ACK'd then sends the other 2 characters in the next packet.
Never does it send the 3 characters each in separate packets.
This separation is causing the problem at the far end when the application
comes to reassemble the char string to determine whether or not it was a
function key that was pressed.
> (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".)
OK, I'll have a look at TCP_CORK, that's another lead.
> 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.
I agree, but at some stage the server app (Pick D3 in this case) has to
make a decision as to whether the <ESC> char it received is being followed
by further chars to indicate that a function key was pressed, or was just
a case of an <ESC> key itself being pressed, or is just a lost soul from
limbo land. Hence it must have some sort of a timeout.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
