🚀 go-pugleaf

Hi

> That depends on how you are accessing the local files to begin with.
> You have to make sure that you are providing your TStream objects in a
> thread-safe manner.  If you have two clients accessing the same file
> at the same time, that would be bad.


Yes, I will put exclusive access on write and read, so client retries will 
be required if this happens.

> And in any case, the OnTransferComplete event handler is always
> synchronized with the main thread.


From your other email, no there is only one (test) client  I haven't got to 
running multiples yet, keeping it simple until I understand how it all 
works.

Maybe the syncronize is why the sequence looks strange in the log.  But see 
the overlapped the trace log from the two applications.  The lines with 
"IdTrivialFTPServer" are the server app trace, the others from the client 
trace.  The put completes, but the server end seems to respond with transfer 
complete some time after the write has finished (1.5s), which seems a long 
time, and this probably explains why my client repeat 'put' sequence fails 
if it happens too quickly after the last.

2007-02-14 08:12:36:0067 : Client1File Write
2007-02-14 08:12:36:0067 : Begin Event
2007-02-14 08:12:36:0077 : IdTrivialFTPServerWriteFile (Client1File)
2007-02-14 08:12:36:0077 : Work Event
....
2007-02-14 08:12:37:0940 : Work Event
2007-02-14 08:12:37:0940 : End Event
2007-02-14 08:12:37:0940 : Client2File Write
2007-02-14 08:12:37:0940 : IdTrivialFTPServerWriteFile (Client2File)
2007-02-14 08:12:37:0940 : Begin Event
2007-02-14 08:12:37:0950 : Work Event
.....
2007-02-14 08:12:39:0432 : Work Event
2007-02-14 08:12:39:0442 : IdTrivialFTPServerTransferComplete (Client1File)
2007-02-14 08:12:39:0442 : Work Event
....
2007-02-14 08:12:39:0822 : Work Event
2007-02-14 08:12:39:0822 : End Event
2007-02-14 08:12:41:0324 : IdTrivialFTPServerTransferComplete (Client2File)



However, just looked at the code for TFTP server (keep forgetting I have 
it!).  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 
further, the rfc1350 says:

   The end of a transfer is marked by a DATA packet that contains
   between 0 and 511 bytes of data (i.e., Datagram length < 516).  This
   packet is acknowledged by an ACK packet like all other DATA packets.
   The host acknowledging the final DATA packet may terminate its side
   of the connection on sending the final ACK.  On the other hand,
   delaying is encouraged.  This means that the host sending the final
   ACK will wait for a while before terminating in order to retransmit
   the final ACK if it has been lost.

So looks like normal behaviour!  So perhaps the client response to a write 
failure is to wait 1.5s (or so) before retrying the file again.

Thanks.

Regards,

Paul