From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 19:24:54 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 59DED16A4CE; Thu, 21 Oct 2004 19:24:54 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 418FA43D46; Thu, 21 Oct 2004 19:24:54 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 8AE9EA4129; Thu, 21 Oct 2004 12:24:53 -0700 (PDT) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90346-02; Thu, 21 Oct 2004 12:24:52 -0700 (PDT) Received: from [192.168.1.102] (wbar4.sjo1-4.28.216.220.sjo1.dsl-verizon.net [4.28.216.220]) by mail.trippynames.com (Postfix) with ESMTP id 08FD6A4121; Thu, 21 Oct 2004 12:24:51 -0700 (PDT) In-Reply-To: <41780672.6AAC705F@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> <41780672.6AAC705F@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 21 Oct 2004 12:24:50 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.619) 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 19:24:54 -0000 >>> 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