Arnau Font wrote:
>> Also, I'm having trouble with slow transmissions. When a download
>> lasts more
>> than 20 minutes the component seems to freeze, 

Does "freeze" mean that the GUI is not repainted?

>> and the component
>> remains in
>> ftpWaitingResponse. 

If the GUI _is repainted, I guess a router/proxy problem.
I recently experienced the same in a non-FTP application.
We solved it by sending some 'real' keepalive bytes from
our client application in regular intervals, triggered by a timer.
The problem with TFtpCli however is that you cannot send a command
while another command is still waiting for a reply. So my only
idea is to try to send some raw, fake FTP-command thru 
FtpCli.ControlSocket.SendStr() to keep the control connection
alive, some command that does not require a data socket.

>> It seems that it doesn't receive the confirmation
>> (FServerSaidDone still remains at false). I suspect that, as the
>> control
>> socket is idle all this time, some device closes it and I can't
>> receive the
>> server confirmation, I only get the DataSocketGetSessionClosed event.
>> I'm behind an ISA Server, I suppose that it closes the control
>> socket, as it
>> isn't sending anything. How can I avoid that?
> In latest downloads there's a new public property KeepAliveSecs to
> enable keepalive packets on the control socket, this should avoid
> the connection from being closed on inactivity.
> I've downloaded the lastest v6 beta, but is still doesn't work. I've
> set the 
> keepalivesecs to 60. Should I change any other property?

So obviously those keepalive packets do not reset the timeout (where
ever it happens) however sending some bytes may help, see above. 

Arno Garrels [TeamICS]

> In the server also says that the download has failed, just after
> finishing 
> the data connection...
> I have a ISA Server 2000, I don't know if that helps...
> Thanks!
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to