Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Nagle algo. in Unix-TCP
Keywords: tcp tinygram RPC X11
Message-ID: <13628@well.UUCP>
Date: 14 Sep 89 17:12:08 GMT
References: <2581@lll-lcc.UUCP> <13394@well.UUCP> <2598@lll-lcc.UUCP>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 36


      It's interesting that the sequence

	SEND
	SEND
	wait for reply

is almost the worst possible case here.  If the application did (rapidly)

	SEND
	SEND
	SEND
	SEND
	wait for reply

on a previously idle TCP connection,
the first send would take place immediately, and the remaining three would
be consolidated into one segment (assuming they are small) which would
be transmitted when the ACK was received for the first send.

      In a UNIX application, the usual way to handle this sort of thing
is to write to to the socket via the standard I/O package, specifying
buffering, and to flush the buffer just before going into a wait state
for any reason.  If you're using SELECT(II) for all input, do a SELECT
poll (with a zero timeval structure) to determine if there is any input,
and if not, flush output buffers before then doing a SELECT which will
block.  The effect of this is that the application accumulates pending
output until it needs some (any) input, then flushes the output.  This
should eliminate the round-trip waits while minimizing network traffic.

      Bypassing the tinygram prevention mechanism is not a good idea if
the software is ever to be used in a wider world than a single LAN.
The impact on gateways is well known, and filling up the gateways of
others with tinygrams is considered antisocial.

					John Nagle