tags:

views:

279

answers:

3

We are using .Net and sockets. The server is using the Socket.Sender(bytes[]) method so it just sends the entire payload. On the other side we are clients consuming the data. Socket.Receive(buffer[]). In all the examples from Microsoft (and others) they seem to stick with a buffer size of 8192. We have used this size but every now and then we are sending data down to the clients that exceeds this buffer size.

Is there a way of determining how much data the server's sent method sent us? What is the best buffer size?

A: 

8192 would be ideal. If you have data which exceed this size it wouldbe better of you to send the data in constant length packets.

The size of data that is sent by server can be checked using the recv function in WINSOCK which has a parameter that gives length of buffer.

ckv
+2  A: 

Even if you're sending more data than that, it may well not be available in one call to Receive.

You can't determine how much data the server has sent - it's a stream of data, and you're just reading chunks at a time. You may read part of what the server sent in one Send call, or you may read the data from two Send calls in one Receive call. 8K is a reasonable buffer size - not so big that you'll waste a lot of memory, and not so small that you'll have to use loads of wasted Receive calls. 4K or 16K would quite possibly be fine too... I personally wouldn't start going above 16K for network buffers - I suspect you'd rarely fill them.

You could experiment by trying to use a very large buffer and log how many bytes were received in each call - that would give you some idea of how much is generally available - but it wouldn't really show the effect of using a smaller buffer. What concerns do you have over using an 8K buffer? If it's performance, do you have any evidence that this aspect of your code is a performance bottleneck?

Jon Skeet
I would like to increase the buffer size if it all possible. We were contemplating just making it 32K but I was worried about the above scenario where I the receive command would not get everything even though I sent it in a single Send.
uriDium
Sorry i forgot to mention that we are doing this in blocking mode. I don't see it making a difference though.
uriDium
@uriDium: You should write your code so that it doesn't rely on receiving everything from a single Send in one Receive. That's not the model that TCP uses - it's a *stream* model. If you want to segment that stream into distinct messages, you should either use a delimiter or write a length prefix for each message so that the client knows how much to read.
Jon Skeet
A: 

It depends upon your protocol. If you are expecting messages in excess of 8192 bytes, then you should increase your buffer size accordingly. But keep in mind this buffer size is only for one call to Receive. If you really want/need to, you can loop over Receive multiple times and copy the received data into an arbitrarily large data structure or buffer.

Also keep in mind it is good practice to call Receive repeatedly until you have verified that you have read all of the data for a given message; even if a single message is less than your buffer size, it still might not all be retrieved by a single Receive call.

Justin Ethier