Removing T/TCP and replacing it with something simpler
sean at chittenden.org
Thu Oct 21 12:24:54 PDT 2004
>>> 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 think you got something wrong here. T/TCP is never ever mentioned
> in this. Memcached is not using T/TCP as far as I can see.
It's not, but I thought setsockopt(2) w/ TCP_NOPUSH enabled the use of
T/TCP in that there was no 3WHS performed on a TCP_NOPUSH'ed
>> 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).
> What syscall do you use to get to the other side in your reverse proxy?
On the client, sendto()/read(). On the server, setsockopt() + write().
>> 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
>> Linux's TCP_CORK)?
> I'm not sure if I can follow you here. TCP_CORK deals with the
> behaviour of connections with Nagle vs. TCP_NODELAY. TCP_CORK allows
> avoid the delays of Nagle by corking (sort of blocking) the sending of
> packets until you are done with write()ing to the socket. Then the
> connection is uncorked and all data will be sent in one go even if it
> doesn't fill an entire packet. Sort of an fsync() for sockets. There
> are no security implications with TCP_CORK as far as I am aware.
Isn't that what NOPUSH does? Or is it that CORK uses a fully
established TCP connection, but blocks sending data until the
connection has been uncorked/flushed? I thought that TCP_CORK had the
same security implications that NOPUSH does (ie, the lack of a hand
I was under the impression that by default NOPUSH would prevent a
connect() until there was a full packet to be sent or the socket had
been closed/flushed. The first/only packet from the client to the
server would contain a SIN+PUSH+FIN + the data for the request, then
the server would come back with a SIN+PUSH+FIN+ACK. Essentially UDP,
but with checksums and packet retransmission built in.
More information about the freebsd-arch