commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Do we really need to read keepalive NOOP responses from FTP server?
Date Tue, 17 Oct 2017 15:29:05 GMT
On 17 October 2017 at 16:01, Basin Ilya <basinilya@gmail.com> wrote:
> Hi sebb
>
>> No, because some FTP servers *do* support asynchronous control channels.
> Do you know any?

I cannot remember the name, but I know I came across at least one when testing.

But even if there were currently no such servers, AFAIK it is
permitted by the RFCs so NET should not assume there are none.

>
> On 17.10.2017 17:54, sebb wrote:
>> On 17 October 2017 at 12:34, Basin Ilya <basinilya@gmail.com> wrote:
>>> Hi.
>>> I'm using
>>> FTPClient.retrieveFileStream()
>>>
>>> and therefore I need to implement keepalive mechanism by my own.
>>
>> Not necessarily.
>>
>> The FTP server does not need the NOOPs.
>> They are only needed to deal with routers that detect the inactive
>> control channel and decide to drop the connection even though the data
>> channel is active.
>>
>>> I wanted to mimic the implementation from FTPClient.CSL, but then I thought:
>>>
>>> Most FTP servers don't reply to NOOPs until transmission has finished and yet,
sending NOOPs helps to keep them alive.
>>
>> No, the FTP servers don't need the NOOPs.
>> And some do reply before data transmission completes.
>>
>>> So we can safely assume that no FTP servers support this and let CSL.cleanUp()
collect all the responses at the end.
>>
>> No, because some FTP servers *do* support asynchronous control channels.
>>
>>> My tests show vsftpd 2.2.2 does not support that and you can send up to 27000
NOOP commands to it until the socket write gets blocked.
>>>
>>> On the other hand, on most FTP servers for each NOOP keepalive FTPClient waits
for 1000 milliseconds for a reply that never comes. This slows things down a little.
>>>
>>> What bad thing will happen, if we remove __getReplyNoReport() from FTP.__noop()
and increment notAcked unconditionally?
>>
>> Try it and see?
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>

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


Mime
View raw message