commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] Commented: (NET-258) Implement A Keepalive Mechanism
Date Tue, 22 Feb 2011 15:55:44 GMT


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:
>             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
> * 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:


View raw message