• Welcome to Valhalla Legends Archive.
 

Appropriate size for received data buffer

Started by warz, March 28, 2006, 04:37 AM

Previous topic - Next topic

warz

What's an appropriate size for the character array, used to store the received data from bnet, that you pass to your recv() function? Is there a maximum size that bnet will send to you at once?

rabbit

The maximum size of a packet is 0xffff bytes, though I highly doubt that has ever happened.  Usually 4096 will be much more than enough to buffer a packet and start buffering the next.
Grif: Yeah, and the people in the red states are mad because the people in the blue states are mean to them and want them to pay money for roads and schools instead of cool things like NASCAR and shotguns.  Also, there's something about ketchup in there.

MyndFyre

I can't speak for the rest, but I read 4, get the length, then read that.  I don't think I've ever received more than about 500 bytes, but it's been a while - things like clan lists can get long.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Joe[x86]

I think MyndFyre's idea is the best, unless the CSocket (CAsyncSocket, whatever) class has some method to get the available number of bytes (java.net.Socket does, I know).

Also, on TestBNCS servers you can expect a silly administrator to add a ton of channels to 0x0B, and you would easily hit over 500.
Quote from: brew on April 25, 2007, 07:33 PM
that made me feel like a total idiot. this entire thing was useless.

MyndFyre

Quote from: J on March 28, 2006, 04:50 PM
I think MyndFyre's idea is the best, unless the CSocket (CAsyncSocket, whatever) class has some method to get the available number of bytes (java.net.Socket does, I know).
(...or just the Windows API, because not everyone uses MFC...)

Quote from: J on March 28, 2006, 04:50 PM
Also, on TestBNCS servers you can expect a silly administrator to add a ton of channels to 0x0B, and you would easily hit over 500.
Well then, it seems that there is a very quick and easy algorithm to do this.
1.) malloc 4 bytes for reading headers and 256 bytes for reading data.
2.) Track the number of bytes specified by the headers.  As you go over, double the size of your buffer, up to 0x10000 (65,536) bytes.

This method has several advantages.
1.) You don't need to continually malloc new buffers - you always read your received data into the same buffer.
2.) Because you read the header first, you can avoid a buffer overflow.
3.) The most realloc's ever needed would be 8, but if they're not needed you can keep memory use down.  (256->512->1024->2048->4096->8192->16384->32768->65536).
4.) It would be extremely easy to encapsulate this into a thread-safe function (the memory reallocation).
5.) Because you're not wasting time doing a silly thing like reallocating new memory to the receive buffer, all you need to do is block-copy your data to a reader, if you even so choose (that's not absolutely necessary).
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.