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

Reply via email to