[PATCH] Using TCP_NODELAY unconditionally

[Rick Jones]

> > In general, I would think that if ssh were acting as a pipe, it
> > might as well set TCP_NODELAY - ostensibly the applications on
> > either end of the pipe are (supposed to be) doing the "right"
> > thing with TCP_NODELAY. In that sense ssh should simply pass the
> > data along since
> 
> I agree in principle. A simple heuristic, like "if an SSHv2
> connection has a no-pty session and at least one forwarded X11
> channel open, then both the client and server ought to be smart
> enough to set TCP_NODELAY" would probably suffice for me. But Nagle
> should probably not be turned off for interactive sessions...
>
> In general with port forwarding you'd hope that the forwarder passes
> traffic along with the same characteristics as the original. If
> you're forwarding, say, CVS, and CVS uses TCP_NODELAY then the
> forwarder ought to use TCP_NODELAY as well, by the your suggested
> principle.
I think that if ssh is operating as a pipe (is that the same as port
forwarding), then if it sets TCP_NODELAY, so long as it does not do
something silly like gratuitously sending logically associated data in
separate sends, it will preserve the behaviour of the apps on either
side - whether they set TCP_NODELAY or not.
Data will arrive at the sockets the way it came-out of the TCPs on
either end.
> If heuristics will do, great. It sounds like it should be simple to fix
> sftp to avoid Nagle. Any other ideas that might fix X11 forwarding? Does
> anyone find it necessary?
Since X11 sets TCP_NODELAY,one could either treat it as an example of
a generic pipe (ie set TCP_NODELAY), or one could treat it as specific
knowledge of the needs of the application - and in this case again set
TCP_NODELAY.
rick jones