[fpc-pascal] LNet
Andreas Schneider
aksdb at gmx.de
Fri Jun 11 19:06:31 CEST 2010
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.
More information about the fpc-pascal
mailing list