I’ve been wondering when the call back that’s provided with a BeginRecieve call is triggered.
- Is it when it received as much data as the buffer can hold?
And if so – what if the data is smaller than the buffer) - Is it when it received one TCP/IP packet?
- Is it something else?
I found a similair question which I will repeat as I can’t put it much clearer:
Now all documentation says that the callback, as specified in
BeginReceive, is called as soon as ‘the data is received’. But this is
rather vague: when exactly is that moment if you don’t know how
exactly that other process is providing data?One criterium is that BeginReceive() is considered completed (and thus
the callbask is called) when the buffer in the state object is filled
upto the specified buffersize. But what if the ‘delivering’ process is
feeding data in unknown quantities and in an irregular pattern? For
instance, if it first delivers 100 bytes consecutively, and then there
is a time interval of 1 millisecond and another 200 bytes follow: does
BeginReceive complete with 100 bytes of incoming data? Or 300?
http://www.pcreview.co.uk/forums/exactly-beginreceive-socket-considered-completed-t2899270.html
My experience is that it is called for any data being available without delay. This means that reads can be rather small, like 1400 bytes or so because that is on the order of the MTU size.
Reads can be multiples of that because if packets arrive out of order all of them are made visible to application the moment the logically first one arrives. You get to read from all contiguous queued packets at once in this case.
I guess your read size will increase on extremely fast connections because your application might fail to dequeue bytes as fast as the network delivers individual packets.
Sidenote: The BeginReceive-callback is called at exactly the same moment Receive would have returned. You don’t get to reduce latency that way. (Latency will actually increase by a tiny amount because async operations can have higher overhead than blocking ones).