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