[PATCH] Using TCP_NODELAY unconditionally

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Jan 23 08:10:19 EST 2002


On Tue, Jan 22, 2002 at 12:52:50PM -0800, Rick Jones wrote:
> Nicolas Williams wrote:
> > But SSH is not all about forwarding other protocols. It's also
> > about character-based interactive sessions.
> 
> True. My discussion about setting TCP_NODELAY was for the case when
> sshis operating as a forwarder. If ssh is operating as an end
> application itself, then a different set of rules/heuristics may apply.

Fine, but what if you're mixing both, interactive sessions and port
forwarding in the same SSHv2 connection? See? Problem.

Also, heuristics can be a bit sucky, in that you have to count on both
sides applying the same heuristics, which is why a global SSHv2 request
for the client to ask the server to enable TCP_NODELAY would be good.

I think at the very least there should be a global SSHv2 request as
above and that if we'll rely on heuristics then it should be the client
that applies them and requests the server to set or not set TCP_NODELAY.

At most SSHv2 connections should always have TCP_NODELAY set and then
Nagle should be a per-channel option.

> The purist in me would say that if ssh is operating as an
> end-application (pseudo-source if you will) then its default behaviour
> should be to _not_ enable TCP_NODELAY. My reasoning is that if ssh is
> receiving data from something "well behaved" it will not matter, and if
> it is receiving data from something _not_ well behaved, it will make a
> huge difference in the network overhead.

Well, since you can mix general port forwarding with interactive
sessions I would say that you can't be a purist on this issue without
also arguing for per-channel Nagle at the SSHv2 level. :) :)

> rick jones
> -- 


Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list