> Unfortunately in this instance 200mS is a problem. The client is 
> performing a LIST every 3 seconds on the server. There may be 
> 300-400 files in the list. All of a sudden the server flags every 
> file as changed and the client has to download every file to see if 
> the change is valid. So now 200mS per RETR accumulates to a 
> significant time.
You need a better FTP server, like the ICS FTP server that has much
better file listing using the control channel instead of the data channel,
to avoid continually opening new sockets.  

> Whereabouts is this code that causes a wait. I would like to 
> experiment with it.

There is no code waiting, for PUT windows messages check the last buffer
has been sent completely before closing the socket.  There is a fail safe
property CloseEndSecs that specifies how long to keep checking data has
been sent, but this is measured in seconds, not milliseconds.  Look in
TCustomFtpCli.DataSocketPutDataSent and TCustomFtpCli.WMFtpCloseDown.  

This does not happen with GET, windows reports the socket closed and we
close the stream and trigger requestdone.  

You really need to enable the debug logging options with loProtSpecDump
to see which events are being called at what times, and where this 'delay'
is being introduced.  


To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to