On 17 October 2017 at 16:01, Basin Ilya <basini...@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 <basini...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
