3 - 5 kb packets?

are 3 - 5kb size packets to much to send in 1 packet or should I split them into < 1kb/packets ? or is a 1kb/packet sufficent?

I'll assume we're talking about TCP and not UDP here. Your program never sends or receives "packets" anyway.

Using the Winsock control you can blast out a ton of bytes using SendData, but data read back with GetData seems to come in chunks of 8K or less.

If you are using a chatty "ack ack" protocol with "go ahead" messages sent to the sender to prompt the next block of data, sending data in chunks up to around 16K can sometimes be optimal even if the data is only returned in 8K pieces.

But a call to SendData does not send a "packet" and there is certainly no guarantee that the receiver will pick it up intact in a single GetData call.

Max data that can be put in one packet, unless you are talking a GigE network is 1514 bytes. So the protocol MIGHT allow you something else, but it will have to split it up.

But that's exactly my point: you don't send "packets" at all via the Winsock control.

You're working far above the level of Ethernet, IP, and even TCP or UDP. Both the Winsock control itself and the underlying Wicksock socket the control uses have buffering and flow control mechanisms active that you can't see.

You can read a large file into a Byte array and send it with a single SendData and it works fine - actually you get the best performance if you do. But a Winsock control at the other end gets a series of DataArrival events, and each time you GetData you'll get at most about 8K in each chunk.

There is a LOT of software between you and the Ethernet (or SLIP, or PPP, or USB, or 802.11, etc. depending on the network hardware and protocol you are using) and even IP packet level. It takes care of transport - that's its job.

"Packet size" does become an issue with UDP of course, but only in terms of the maximum size datagram you can send without fragmentation. With UDP this can become an important consideration.


With TCP most of the time people should be talking about fragments since that's what they're dealing with: fragments of a contiguous stream. When you impose a structure on top of that stream it is better to talk about frames or messages - logical units of data analogous to records in a file. That catch is that we have file I/O operations in VB that handle breaking things up into records (Print#, Input#, Line Input#, etc.) and the Winsock control doesn't take care of this for us.

On the other hand that all assumes TCP. If you are working with UDP then packet size does matter. The protocol doesn't guarantee that a packet won't get divided, but if a UDP packet gets divided then there is no guarantee that both pieces will get through, or which order they will arrive in. Therefore, if you exceed the packet size of the underlying network you really need to be adding something to your data to be able to ID it such that you know that you have lost a packet in the middle. With TCP it doesn't matter, but with UDP it might.

With UDP there is no guarantee any of it will get through.

The point is that in neither case are you working with packets at all. TCP is a reliable stream and UDP is an unreliable, unsequenced series of datagrams. Of course that can also be a strength for UDP since datagrams don't have to wait for stream reassembly like TCP does.

But I assume we're talking about TCP in this thread until the OP says otherwise, and more specifically about the size of SendData chunks at the sender's end.

Fair enough. I guess we wait.