[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997866#comment-12997866
]
Sebb commented on NET-258:
--------------------------
I don't think it's worth the effort to provide a general keep-alive. It's
tricky to co-ordinate.
The timeout needs to be chosen carefully, regardless of whether we use the
listener method or a separate thread. There would only be a problem maintaining
the keep-alives if the time between blocks was of the same order as the control
timeout. In which case the user has other problems, as the control timeout is
normally measured in minutes...
It's not possible to synchronise across the command-reply pair for RETR - that
would prevent the NOOPs from being sent - and I'm not sure it's possible to do
so for all other command sequences. That's why I think the thread needs to be
confined to the STOR/RETR methods, where the sequence is known, and the code
can stop the NOOPs as soon as the transfer completes.
> Implement A Keepalive Mechanism
> -------------------------------
>
> Key: NET-258
> URL: https://issues.apache.org/jira/browse/NET-258
> Project: Commons Net
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Rory Winston
> Assignee: Rory Winston
> Attachments: ftp-keepalive.diff
>
>
> For routers/firewalls that terminate idle connections, a separate heartbeat
> mechanism may need to be implemented to keep the control connection active.
> Some potential issues:
> * Synchronization between a heartbeat write and a __getReply() on an active
> control connection command;
> * Should use the NOOP command as a heartbeat signal;
> * Make the timeout configurable;
> * Default SocketImpl::setKeepAlive() wont do here.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
