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 Wed, 23 Feb 2011 16:14:38 GMT


Sebb commented on NET-258:

I've been looking at the code in more detail - unfortunately, __getReply() is not thread-safe,
because shared variables are updated without any synchronisation.
This would need addressing if a separate thread was to be used.

However, during testing of the listener approach I came across another issue, which is that
not all FTP servers support concurrent access to the control port during data transfer. They
are supposed to, but not all do. If one sends a NOOP (or STAT, which is intended for use during
transfer, see RFC 1123 /, it will be sent, but the reply won't arrive until the end
of the transfer, and in the case of the listener approach this means the transfer will hang.
Even using a separate thread won't help here, as the thread will hang waiting for the first
reply. I don't think it's sensible to send the NOOP/STAT without waiting for a reply.

So I think a different approach needs to be used - something that tells the router that the
control connection is active, without needing a response from the server.

> 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