TCP_NODELAY in Cygwin port

[Kevin Steves]

On Thu, Oct 31, 2002 at 11:28:11AM -0500, Brian Genisio wrote:
> I am sorry if this is not really a bug, and I am missing something, but I am running into an issue with port forwarding in SSH.  I am using 3.4p1 of SSH on both sides.
> 
> I am running the ssh daemon on a Slackware Linux 8.0 machine, and the ssh client is running in Cywgin version 1.3.13.  The ssh client is creating about 7 port forwards in a mix of local and remote forwarding 
> types.  Everything with this setup works great.
> 
> I have an application that runs on the linux side that port forwards to the Cygwin side, and sends a small control packet (4-8 bytes) at a rate of 30 times per second to an application on the Cygwin side.  Because 
> of this, the control application uses TCP_NODELAY in order to send it out as soon as it can.
> 
> If I do not use SSH port forwarding, the control packets are sent at a steady rate.  If I use the SSH port forwarding, the data is buffered, and sent in bursts.  With this, the packets build up, so nothing is sent for 6 
> to 10 frames, and then all are sent at once.  This makes for jerky control.
> 
> I have looked into the OpenSSH release notes, and noticed that you added TCP_NODELAY on your endpoints for TCP port forwarding, though it does not seem like it is working properly.
> 
> Unfortunately, I have been unable to tell weather the burst is happening between the sshd and the ssh, or the ssh and the application.  As I mentioned, if my control program connects directly to the application, 
> no buffering is used.
> 
> Do you have any idea to why this is happening?  Is there something wrong with the port forwarding implementation of SSH and TCP_NODELAY in Cygwin possibly?  I ran both sides in debug mode, and it stated 
> that TCP_NODELAY was indeed set.  

i don't know.  as you can see, we call set_nodelay() for all ends of
port/x11 forwards.  i'm not really clear on where source/sink sockets
are from the above.  can you replace the cygwin piece with non-cygwin
and hence eliminate cygwin+MS TCP stack from the picture and see if
behaviour changes?  otherwise, you need to trace (tcpdump) on all ends
and determine where delays originate from.