> 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. Angus -- 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
