Removing T/TCP and replacing it with something simpler

[Sean Chittenden]

>>> However something like T/TCP is certainly useful and I know of one
>>> special
>>> purpose application using it (Web Proxy Server/Client for high-delay
>>> Satellite
>>> connections).
>>
>> 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:
>>
>> http://lists.danga.com/pipermail/memcached/2003-August/000111.html
>
> 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 
connection.

>> 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)?
>>
>> http://seclists.org/linux-kernel/2001/Feb/0993.html
>
> I'm not sure if I can follow you here.  TCP_CORK deals with the 
> different
> behaviour of connections with Nagle vs. TCP_NODELAY.  TCP_CORK allows 
> to
> 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 
shake).

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.

-sc

-- 
Sean Chittenden