Whats the maximum, or whats the "best" amount of data that you should send with winsock? Say you have a file to send (few mb's), or a whole list of names or whatever, what size parts should you break all that data up in to?
Printable View
Whats the maximum, or whats the "best" amount of data that you should send with winsock? Say you have a file to send (few mb's), or a whole list of names or whatever, what size parts should you break all that data up in to?
I take it you're planning to use the TCP protocoll?
Ive never heard of any optimal size to break up your data into. As a matter of fact, since the TCP connection between the two peers is a stream, I would just send as much data as possible at once, and let the underlying TCP protocoll control the transfer speed if it needs too.
TCP will automatically break up the data into segments and send them, you have no control over that.
Dillatente (sorry if I spelled your name wrong) is probably the guy to ask, but from my experience, it seems to usually break data up into segments of 4096 bytes (4KB). So I personally never send more than 4KB at a time. This won't really have any noticeable effect on transfer speed. I've sent as little as 32 bytes at a time (for testing) and the transfer speed was more or less the same, since smaller segments transfer faster.
You should also take into account the buffer of the Winsock control itself. You don't want to put that much into it at one time...it will handle it itself but there is just no justifiable reason to send more than 4KB at a time (I personally use 3KB for file transfers).
Edit: Sorry, somehow I missed the c++ of the thread title, so ignore the comment about the Winsock control, but the rest still applies regardless of what language you are using.
This is a bit like answering 'what's the optimum length of a piece of string?'.
As Atheist points out, TCP streams the data so, on the one hand, smashing the data through is one way to go. However, it has its limits and very large Blocks (eg >128Kb) can cause buffer starvation in the sender, and in the case of a 'slow' receiver, TCP congestion control may kick in and request the sender to stop sending whilst it catches up. This will cause delays in the transfer. Also, the low level protocols utilise non-paged memory for buffers and there is a finite limit, of about 1/8 of total real memory, so, again, with huge buffers that resource could get exhausted. Saying that, I have successfully transfered as much as 10Mb with one send (as a test of socket memory management, I wouldn't necessary recommend doing that in anger)
On the other hand, blocking the data, sending a block, waiting for the send to complete and then sending the next block, etc. gives a degree of control of resource usage, in as much as the use of buffers limits the amount of memory being consumed. and gives the receiver the opportuity to acknowledge successful reception, and / or give the opportuity for the transfer to be cancelled mid-stream. So to some extent your Application Protocol may dictate which way to go.
Note the 'wait for the send to complete' bit, it's of little value blocking the data and then just going round a loop sending each block, since the sending is asynchronous (that's why you often see, in VB (erroneous) implementations a 'DoEvents' after the send - it gives the buffers a bit of a breather, since the data is just being smashed through, and helps circumvent buffer starvation)
Really, it's a matter of 'Horses for Courses', in most of my data transfer applications, I use a Buffer of 32Kb which seems to be a happy medium for my particular configuration and performance requirements.