>> -----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
>>>>> 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]
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