On 02/06, Simon Sandström wrote: > Hi, > > I have a few questions on how the FTPClient's control channel keep-alive > feature works and how to implement a custom one to be used for when > using the xxxFileStream methods. > > First of all, how is concurrency handled when using e.g. storeFile and > setControlKeepAliveTimeout? As I've understand it the OK reply on > control channel for storeFile is sent async by the FTP server as soon as > the transfer on data channel is done. Isn't there a risk that a NOOP > command was just sent to the server and that the two replies for > storeFile() and NOOP are interchanged by FTPClient? >
So I did some more digging and realized that FTPClient's keep-alive functionality doesn't really need to care about concurrency as the same thread that's doing the file transfer is also sending the NOOPs. I think that we will try to implement a similar keep-alive mechanism. Call it each time a chunk has been written to the FTP output stream and send a new NOOP if more than x minutes has elapsed since the last NOOP was sent. Now I'm just wonderin, would it work to use the public methods on FTP/FTPClient sendNoOp() and getReply() instead of the protected methods __noop() and __getReplyNoReport() which FTPClient/CopyStreamListener use internally? Also, am I understanding it correct that the CopyStreamListener's notAcked variable and the __getReplyNoReport() usage in cleanUp() is used to handle the case where the FTP server doesn't handle messages on the control channel while a file transfer on the data channel is active? So in that case the FTP server will not send NOOP replies until the file transfer has completed, and then possibly send multiple replies (notAcked number of replies) which we then would need to receive, until finally receiving the reply for the file transfer using completePendingCommand()? Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
