Dan wrote: >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:twsocket- >> [EMAIL PROTECTED] On Behalf Of Arno Garrels >> Sent: 31 March 2007 13:57 >> To: ICS support mailing >> Subject: Re: [twsocket] Questions about FTPClient >> >> Dan wrote: >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] [mailto:twsocket- >>>> [EMAIL PROTECTED] On Behalf Of Arno Garrels >>>> Sent: 31 March 2007 12:24 >>>> To: ICS support mailing >>>> Subject: Re: [twsocket] Questions about FTPClient >>>> >>>> Dan wrote: >>>>>> So obviously those keepalive packets do not reset the timeout >>>>>> (where ever it happens) however sending some bytes may help, see >>>>>> above. >>>>>> >>>>> >>>>> Try sending the NOOP command periodically whilst >>>>> downloading/uploading. Most servers should support this. >>>>> Not sure >>>>> how the component will handle the response if it's waiting for the >>>>> response from the GET/PUT though. >>>> >>>> You are right! >>>> A response to a NOOP before GET/PUT finished would kill a transfer. >>>> However some (most?) servers queue client requests, the NOOP >>>> responses would the be received after the transfer completed. ICS >>>> FTP server does not queue requests. >>> >>> In my experience, most FTP servers treat a NOOP in a special way and >>> will process it and reply even during a transfer. It's worth a try. >> >> If they reply at once the client would treat the NOOP-response as an >> response to GET/PUT, thus data socket will be closed, see procedure >> TCustomFtpCli.Next2GetAsync. The FTP server of my ISP however doesn't >> reply until PUT/GET completed, just tested. Instead, after the >> download succeeded I was bombed with plenty of NOOP-responses. >> > > Yes, the client would have to be modified in case the server replies > to the NOOP during the transfer. I haven't used them for a while but > I believe DrFTPd, Serv-U and glftpd do this. I also remember it was > a reply code that could be differentiated from the usual data > transfer replies.
The reply code is "200" (command OK). > > Anyway, whether the server replies during or after the transfer, it > should be sufficient to keep the connection alive as routers will see > the data being transmitted. I think it would be hard to handle especially since responses may return at any time, so far I have no solution. But usually a router should keep a port open when it sees a TCP-keepalive packet, problem of the OP may be that the proxy replies to keepalives but self doesn't send such packets to the server? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > > Dan -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
