[PATCH] Using TCP_NODELAY unconditionally

[Kevin Steves]

On Tue, 22 Jan 2002, Rick Jones wrote:
:I guess what I am driving at is that unless there are gratuitous things
:being done by SSH to further break-up the data it is forwarding, setting
:TCP_NODELAY will "preserve" the on-the-wire appearance of the
:applications at either end. It does not matter if they set TCP_NODELAY
:or if they did not.
:
:If the app did not set TCP_NODELAY, its first small send will arrive at
:ssh's socket, and ssh will send that along (yes?). The ACK from the ssh
:host will be sent back to the app's TCP, and the rest of the small sends
:will be send and will arrive and ostensibly be recieved in one swell
:foop by ssh (it does use a reasonably large recv buffer yes?) and then
:will be passed-along by ssh on the other side.

we don't currently set SO_RCVBUF/SO_SNDBUF anywhere.  more to look at.

:If the app _did_ set TCP_NODELAY, all the small sends will start
:arriving, and it will be a race between SSH and the remote. If ssh is
:faster than the remote, then the sends ssh makes out the other side will
:also be small, just like the app did originally. If SSH is not quite as
:fast, those little sends will accumulate in the socket buffer and ssh
:will then read larger chunks and presumeably send larger chunks out the
:other side.

thanks.  we need to do some testing.  this sets the TCP forwarding sockets
(source and sink) to TCP_NODELAY.

Index: channels.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.163
diff -u -r1.163 channels.c
--- channels.c	27 Jan 2002 14:57:46 -0000	1.163
+++ channels.c	28 Jan 2002 19:57:32 -0000
@@ -1132,6 +1132,7 @@
 			error("accept: %.100s", strerror(errno));
 			return;
 		}
+		set_nodelay(newsock);
 		nc = channel_new(rtype,
 		    nextstate, newsock, newsock, -1,
 		    c->local_window_max, c->local_maxpacket,
@@ -2325,6 +2326,7 @@
 		return -1;
 	}
 	/* success */
+	set_nodelay(sock);
 	return sock;
 }