From owner-freebsd-net  Thu Mar 25 16:51:48 1999
Delivered-To: freebsd-net@freebsd.org
Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.50.17])
	by hub.freebsd.org (Postfix) with ESMTP id BBBBE14E95
	for <freebsd-net@FreeBSD.ORG>; Thu, 25 Mar 1999 16:51:43 -0800 (PST)
	(envelope-from kml@gecko.nas.nasa.gov)
Received: from gecko.nas.nasa.gov (kml@localhost)
	by gecko.nas.nasa.gov (8.9.1a/NAS8.8.7n) with ESMTP id QAA17517;
	Thu, 25 Mar 1999 16:51:09 -0800 (PST)
Message-Id: <199903260051.QAA17517@gecko.nas.nasa.gov>
To: Jim Shankland <jas@flyingfox.com>
Cc: j@lumiere.net, freebsd-net@FreeBSD.ORG
Subject: Re: mbuf clusters and socket send buffers (was Re: 3.1-STABLE dies on 40+ connects) 
In-reply-to: Your message of "Thu, 25 Mar 1999 16:54:16 PST."
             <199903260054.QAA22060@biggusdiskus.flyingfox.com> 
Date: Thu, 25 Mar 1999 16:51:09 -0800
From: "Kevin M. Lahey" <kml@nas.nasa.gov>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

In message <199903260054.QAA22060@biggusdiskus.flyingfox.com>,
Jim Shankland writes:
>A thought related to this discussion:  does it make sense to allow the
>send buffers to be larger than the peer's advertised window size?
>In other words, why "preposition" those bytes in the kernel before
>the peer has indicated a willingness to accept them?

Interestingly enough, no memory is actually used until data arrives.
The socket buffer size is merely a cap on the amount of memory that 
could possibly be allocated for that connection.

Kevin
kml@nas.nasa.gov


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message