From owner-freebsd-hackers Wed Jun 20 9: 4:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7E4A437B403 for ; Wed, 20 Jun 2001 09:04:47 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5KG4ij09941; Wed, 20 Jun 2001 09:04:44 -0700 (PDT) (envelope-from dillon) Date: Wed, 20 Jun 2001 09:04:44 -0700 (PDT) From: Matt Dillon Message-Id: <200106201604.f5KG4ij09941@earth.backplane.com> To: "Ashutosh S. Rajekar" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Wed, 20 Jun 2001, Matt Dillon wrote: : :> This is fairly easy to do. You can use SO_SNDBUF and SO_RCVBUF :> socket opts to adjust the tcp buffer space. You can make the default :> small and receive-centric and when you think you've got a good :> connection you can pump it up. :> :> I used fixed assymetric TCP buffering at BEST - I made the send buffer :> a lot bigger then the receive buffer. Or, more to the point, I left :> the send buffer pretty much alone and made the receive buffer smaller. : :True, but what I meant is that the amount of memory required to hold a :connection from a client with SYN-ACK-SYNACK already being sent shouldbe :really minimal, like around 100 bytes or so ... and this structure is :upgraded to look like a socket structure only when the proxy decides that :it can take more connections. Otherwise neither are we wasting too much :memory, and it won't be really bad to jsut throw away the connection. : :-ASR Ah, now I get it. The Linux people were messing around with a stateless SYN/ACK algorithm at one time. I never liked the idea myself but the concept had merit. It looks like it wouldn't be too difficult to hold off creating the socket around the pcb until the handshake is complete, but waiting beyond that (for actual data to come in) would be messy. I don't think this represents the biggest problem you would face, though. It is far more likely that hung or slow connections (e.g. the originator goes away without disconnecting the socket or the originator is on a slow link) will represent the biggest potential problem. It's too bad we can't 'swap out' socket buffers! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message