Removing T/TCP and replacing it with something simpler
sean at chittenden.org
Thu Oct 21 11:31:49 PDT 2004
> I intend to remove T/TCP (transactional TCP) support from our TCP
> implementation for the following reasons:
The special cases are evil.
> However something like T/TCP is certainly useful and I know of one
> purpose application using it (Web Proxy Server/Client for high-delay
Actually, there are two/three programs that I know of that use it.
memcached(1), which found a fantastic decrease in its benchmarks.
Here's an excerpt from the following link:
> I benchmarked 3 different methods of doing network I/O:
> 1) the default way, with the Nagel algorithm.
> 2) using TCP_CORK (Linux, same as TCP_PUSH on BSD)
> 3) using TCP_NODELAY
> I measured both real time and number of packets on the wire.
> The test was doing 2,500 deletes, sets, and gets, then a 2,500
> Seconds Packets
> DEFAULT 102.48 22638
> TCP_CORK 3.88 15105
> TCP_CORK 3.87 15108
> TCP_CORK 3.86 15105
> TCP_NODELAY 3.99 20169
> TCP_NODELAY 4.04 20170
> TCP_NODELAY 4.00 20170
and an internal reverse proxy server/modified apache that I've hacked
together (reduces latency in a tiered request hierarchy a great deal,
on order of the benchmarks from above).
That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4).
However it gets implemented, I don't really care. If ttcp(4) is ready
to bite the dust, so be it, but extensions/options like this are
fantastically useful to those who know about its existence/usefulness.
Good luck with the replacement. :)
In 2001, there was a push to make Linux's TCP_CORK option behave the
same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still
a goal, or are we going to kick this change off to the Linux folk to
have them play catchup (to what sounds like a more secure option than
More information about the freebsd-arch