Date: Thu, 21 Oct 2004 12:24:50 -0700 From: Sean Chittenden <sean@chittenden.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler Message-ID: <E0C34A72-2396-11D9-9171-000A95C705DC@chittenden.org> In-Reply-To: <41780672.6AAC705F@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0C34A72-2396-11D9-9171-000A95C705DC>