Re: Optimal read buffer size?
Re: Optimal read buffer size?
- Subject: Re: Optimal read buffer size?
- From: Chaz McGarvey <email@hidden>
- Date: Wed, 18 May 2005 12:56:32 -0600
On May 18, 2005, at 12:35 PM, Justin Walker wrote:
On May 18, 2005, at 11:06, Chaz McGarvey wrote:
I find that when I write network code, I never really know how big
I should make the read buffer. Some protocols have only short
packets so I usually have a pretty small buffer, or only read in
one packet at a time, but if I'm reading in a very big packet like
a mult-megabyte resource download that I'm writing to disk, is
there a sweet spot that requires the fewest read calls and doesn't
waste (much) memory?
There is no such thing. First, your app doesn't worry about
packets, unless you are dealing with a datagram-based protocol (and
generally, those have limited packet size); and second, the kernel
handles all the buffering, and deals with it in a much different
way than you do in an application.
What are your concerns?
Sorry. I mean "packets" not in the TCP sense, but rather as a block
of information as defined by the high-level protocol. For example,
HTTP packets can get very large if the server is sending a big
resource. I don't really know how the kernel handles sockets, but I
have assumed that it has its own limited buffer. My question
involves getting the data from the kernel into my own buffer so it
can be written to disk. I would want to do this as fast as possible,
and it seems like if my own application buffer was too small, I would
be calling the read function (probably recv as it were) more often
than is necessary. Likewise, the kernel can only return so much data
during one call (I think) so creating a buffer too big might just
waste memory. So I'm wondering if there is an optimal size.
It seems like I read somewhere that calling recv often with a small
buffer is very inefficient, but I don't want to waste memory either
so that's why I'm asking. Sorry, I haven't had a lot of experience
with network programming; hope my question is understandable.
Thanks,
chaz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden