Date: Thu, 21 Oct 2004 20:56:50 +0200 From: Andre Oppermann <andre@freebsd.org> To: Sean Chittenden <sean@chittenden.org> Cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler Message-ID: <41780672.6AAC705F@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Chittenden wrote: > > > I intend to remove T/TCP (transactional TCP) support from our TCP > > implementation for the following reasons: > > The special cases are evil. Indeed. > > 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. > 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? > That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4). Ah, I'm not going to remove TCP_NOPUSH. It can live independ of T/TCP. While this option has been introduced together with T/TCP enabling it does not make you use T/TCP. > 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. :) Thanks. > 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. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41780672.6AAC705F>