Date: Wed, 20 Jun 2001 09:04:44 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "Ashutosh S. Rajekar" <asr@softhome.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory Message-ID: <200106201604.f5KG4ij09941@earth.backplane.com> References: <Pine.LNX.4.21.0106201253440.1441-100000@vangogh.indranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106201604.f5KG4ij09941>