Ok, so I found these two that support it: - BulletProof FTP Server - Pure-FTPd
Will test further. On 17.10.2017 18:29, sebb wrote: > 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
