Re: preventing data from being mangled
From: David Schwartz (davids_at_webmaster.com)
Date: 11/14/03
- Next message: Nils O. Selåsdal: "Re: What to close after fdopen"
- Previous message: Eduardo: "Re: how to get remainning size of send buffer in unix sockets?"
- In reply to: Corey Murtagh: "Re: preventing data from being mangled"
- Next in thread: Corey Murtagh: "Re: preventing data from being mangled"
- Reply: Corey Murtagh: "Re: preventing data from being mangled"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 14 Nov 2003 00:39:59 -0800
"Corey Murtagh" <emonk@slingshot.co.nz.no.uce> wrote in message
news:1068784385.758069@radsrv1.tranzpeer.net...
> Personally I just find it simpler to transfer the remainder into a
> string that I can append to next time through the loop. Depending on
> how you do it, and how often, it shouldn't be terribly inefficient. The
> bigger the buffer the better though, since you want to eliminate as many
> part-message copies, and as few part-reads, as possible.
> Of course if the string class in inefficient, my way will suck arse
> compared to than yours :)
I would suspect your way is likely to be less efficient than mine, but
the inefficiency would be in an infrequently used code path. Most of the
time, the data you read will consist of some number of complete lines.
You may be surprised to find that the buffer size doesn't significantly
affect the number of part reads. Generally the client outpaces the server
(since it has little else to do) and the network is slower than either
(assuming the server isn't on the same LAN as the client). So the program
will wind up receiving data roughly in chunks the same size as the packets
flowing over the network, assuming the buffer exceeds the MTU.
In the rare case where the client doesn't get back to calling read or
receive for two packets, the buffer size won't matter so long as it's at
least twice the MTU. 4Kb is more than twice the typical MTU for ethernet. So
an 64Kb buffer won't receive more data than a 4Kb buffer unless you don't
get around to calling read/recv for the time it takes 3 packets to traverse
the network.
DS
- Next message: Nils O. Selåsdal: "Re: What to close after fdopen"
- Previous message: Eduardo: "Re: how to get remainning size of send buffer in unix sockets?"
- In reply to: Corey Murtagh: "Re: preventing data from being mangled"
- Next in thread: Corey Murtagh: "Re: preventing data from being mangled"
- Reply: Corey Murtagh: "Re: preventing data from being mangled"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|