Am Freitag 11 Juni 2010, 18:50:56 schrieb Felipe Monteiro de Carvalho: > And from my tests Get is indeed returning the amount read. I still > don't know if half a packet could be received in the OnReceive event > or if it only returns an integer amount of packets. That makes > difference in the algorithm to separate the packets.
IMHO your packets (not the TCP ones, I mean you own protocol) should always account for incomplete packets. Advantages: you can send more than the TCP window allows (which is usually around 60k bytes IIRC), and it doesn't matter if you get more than one packet with your Get - which also can happen. I usually keep a pretty simple binary protocol. A Packet consists of a Packet ID (byte or word or whatever amount of possible packets you need), and if that doesn't imply the size, that one too. So let's say packet IDs 1 to 5 are fixed size, I wouldn't need to supply their size too - would be a waste of bandwidth. Packet ID 6 however contains a text, so right after the packet ID I also send the expected packet size. On Receive, I write all that Get returns into a buffer (a queue to be more precise). Then I loop through that buffer for as long as it contains data and as the size of the buffer is equal or greater than the size of the next packet. Once I'm out of that loop, I get back to the wait-for-more state (i.e. Get, Get, Get :D) I do the same when sending: I put everything to send into a buffer, and then send it in as much chunks as necessary - Send will return how much it actually sent, that's the amount I take out of my send-buffer, and repeat, until the buffer hits zero or until the amount Send returns equals the amount in the buffer (whatever you prefer). If you want to see that implementation, let me know, it's opensource anyway. Best Regards, Andreas. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal