From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:56:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3609616A4D7 for ; Thu, 21 Oct 2004 18:56:50 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA9D643D5A for ; Thu, 21 Oct 2004 18:56:46 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79653 invoked from network); 21 Oct 2004 18:55:20 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 18:55:20 -0000 Message-ID: <41780672.6AAC705F@freebsd.org> Date: Thu, 21 Oct 2004 20:56:50 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Chittenden References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:56:50 -0000 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