It sounds like you need to re-think some assumptions about how TCP/IP works.
Sockets are a stream-based protocol, so there's no concept of "messages". It's all just a series of bytes, one after another. Any "message" you send can be split into multiple parts, or combined with other packets by the underlying network; and there's nothing you can do about it.
So what you need to do if you must send data as messages is encapsulate your data in an envelope, which as one of it's first things it sends is the size of the message. On the receiving end, you read the size, and then you know how many more bytes to read to get a complete message.
If you're sending 4000 bytes as a message, and the network breaks it up into 3 packets (which it almost certainly will, as the default MTU size is 1500 bytes), when you go to read from the socket, you'll read the first 10 bytes (say), inside of which is the message size. You now know how long to read for -- 3990 more bytes. So you issue a read command for that many bytes. But the network has only sent you 1490 bytes so far, so you read that, append it to a buffer, and issue another read for 2500 bytes. The network now returns you 1500 bytes, so you append that to your buffer, and issue a read for the 1000 remaining bytes.
This time the network gives you the remaining 1000 bytes -- you go off and do your business, then issue another read for 10 bytes. And so forth.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first