🚀 go-pugleaf

Hi Remy,

> The transfer complete is done when the file write thread is destroyed. 
> The file write thread has a default receive timeout of 1.5s.  So it looks 
> like the server is timing out on the write operation.  Reading

I've been looking through the code for the server and client for these 
components in Indy9.  Do you think it would be better for the server to 
release the file handle when the last block has been read/written, and for 
the server to just keep re-transmitting the last block, or process the last 
ack?  This way the file handle is released early for use, not sure if the 
transfer complete should also be called then too?  Any impacts?

I've determined the following behaviour from the code:

Server:

1)  The receive timeout is the same regardless of buffer size (1.5s).  The 
server has a three retry receive timeout limit.
2)  The server waits 4.5s in total if nothing is received (if not processing 
last block).  Otherwise its 1.5s.
3)  The server retransmits the previous DATA or ACK block if it receive 
timeouts.
4)  If the client misbehaves when reading and sends an ACK with the wrong 
block, the server will continuously re-transmit the previous block. Or if 
the server and client get out of sync (eg. due to buggy implementations).
5)  If the client misbehaves when writing and sends a block with an 
unexpected block number, the server will continuously re-transmit the 
previous ACK. Or if the server and client get out of sync (eg. due to buggy 
implementations).

Client:

1)  Any receive timeout terminates transfer.
2)  Only the server checks the block sequences, the client assumes the 
server block numbers are always correct, and only checks that they increase.

Regards,

Paul