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?

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.

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.

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 author=J link=topic=14608.msg149284#msg149284 date=1143586206]
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).
[/quote]
(...or just the Windows API, because not everyone uses MFC...)

[quote author=J link=topic=14608.msg149284#msg149284 date=1143586206]
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]
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).