[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