Hi sebb > No, because some FTP servers *do* support asynchronous control channels. Do you know any?
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
