[net] questions on FTPClient's control channel keep-alive feature

[Simon Sandström <si...@nikanor.nu>]

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?

We are using FTPClient in our application and use the xxxFileStream
methods for transferring files, which means that we need to implement
the keep-alive feature ourselves. The work-in-progress implementation
simply starts a periodic task that calls sendNoOp() every 30 seconds
while the transfer is in progress. When the transfer thread has copied
all bytes to the output stream the task is stopped (gracefully, waiting
for sendNoOp() to complete in case the task is running) and then we
finally call completePendingCommand(). I guess that my question here is
the same as above, can there be any concurrency issues here from e.g.
sendNoOp() reading the reply that completePendingCommand() is supposed
to receive?

Finally, would it be possible to have the sendNoOp()-task described
above running at all times, even when no file transfer is in progress?
It would make the implementation simpler: just start the task when
FTPClient is connected and stop it when it disconnects. If there are no
concurrency issues for e.g. storeFile() and sendNoOp() then there
shouldn't be any for e.g. listNames() and sendNoOp() either, or?

Thanks in advance!


Regards,
Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org

Re: [net] questions on FTPClient's control channel keep-alive feature

[Simon Sandström <si...@nikanor.nu>]

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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org