Ok, this is a little embarassing... As some of you probably have
noticed, I managed to get vacation set up wrong, and I've had some
mail bounces. And the funny part is that mailman decided I shouldn't
get any more lsh-bugs mail.
Anyway, I've now reenabled mail delivery, and I have read the
TCP_NDELAY discussion in the mail archive. I'm not terribly familiar
with Nagle, but I have some comments:
1. When having an interacting session, and sending two keystrokes
"X" and "Y", one may end up with loads of IP packets:
Client Server
---> "X" First keystroke (a)
<--- TCP ACK Ack of the data (b)
<--- SSH ADJ SSH_MSG_WINDOW_ADJUST (c)
---> TCP ACK Ack of above message (d)
<--- "X" The server pty echoes the data (e)
---> TCP ACK Ack of the echoed data (f)
---> SSH_ADJ SSH_MSG_WINDOW_ADJUST (g)
<--- TCP ACK Ack of the above message. (h)
---> "Y" Next keystroke (i)
... Etc
Then TCP uses extra delays to try to get the acks and echoes into
fewer IP packets, in order to waste less bandwidth. In general,
that seems like a good thing to do, and ideally, (b), (c) and (e)
should get lumped together into one IP packet, and so should (d),
(f), (g) and (i).
2. I'm not sure which part of this trick is the "Nagle algorithm" ,
and disabled, and I'm not sure in which direction it is most
important. To optimize this, one would need to look at some
packet traces.
3. I'm not personally experiencing any lagginess, but perhaps I'm
too tolerant, or use a too fast network (I don't use anything
slower than adsl on a daily basis. At the moment, I'm typing over
an interactive lsh/lshd connection over a 9 hop network, 10MB at
my end point, and a 10ms roundtrip time). But I'm sure this is
system and IP-stack dependent, so I'll be happy to add TCP_NDELAY
call, if that helps for other people.
4. There's also one additional source of small delays in lsh: When
setting the client tty into raw mode, lsh fiddles with the VMIN
and VTIME values (exactly if and how has varied a little between
versions). The intent is that if you type reasonably fast, there
should not be a simple one-to-one correspondence between
keystrokes and IP-packets, to make it a little harder for an
eavesdropper to observe your typing pattern. Again, some packet
traces would help to determine if this really works well. The
code is in unix_interact.c:
static struct terminal_attributes *
do_make_raw(struct terminal_attributes *s)
{
CAST(unix_termios, self, s);
CLONED(unix_termios, res, self);
CFMAKERAW(&res->ios);
/* Modify VMIN and VTIME, to save some bandwidth and make traffic
* analysis of interactive sessions a little harder. */
res->ios.c_cc[VMIN] = 4;
/* Inter-character timer, in units of 0.1s */
res->ios.c_cc[VTIME] = 1;
return &res->super;
}
This should result in an extra delay of MAX(0.1s, 3 * your intertyping
time).
I'd be happy for corrections to this description, as well as
experiments with changed TCP and TTY options. The patch that adds an
setsockopt(..., TCP_NODELAY) to io.c:io_connect seems to hack at the
right place for the client. There should probably be configurable so
that it is used only when running under a tty. For the server side of
things, the corresponding funtion seems to be io.c:do_listen_callback.
As some noticed, after editing io.c, the Makefile will want to
recreate io.c.x, which will fail if you don't have guile or scsh
installed. For these changes, it should be safe to just touch io.c.x
to convince make that it is up-to-date.
Best regards,
/Niels
_______________________________________________
lsh-bugs mailing list
[EMAIL PROTECTED]
http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
