"KarlLogan" <karl_logan@yahoo.com> wrote in message
news:47b20b16@newsgroups.borland.com...
> It is being used from within a secondary thread.
Then the only way a long transfer can be freezing the rest of the
application is if the worker thread has become deadlocked and the main
thread waits on the worker thread.
> When I say "gets blocked", I mean, **that thread** is waiting
> infinilty ater the put command sometimes (especially behind a
> NAT, but not only).
Then Put() is waiting for a response from the server that never arrives.
> Incresing the timeout property on the **server*** does helps
The timeout on what, though? The control connection or the data connection?
One thing to keep in mind is that not all routers/firewalls are FTP-aware.
Many that are not will close an idle control connection while the data
connection is busy transferring a large file. If that happens, Put() should
be raising an exception eventually, unless the router/firewall closes the
control connection abnormally. In which case Indy may not be able to see it
for a long long time.
> I'm guessing that if the put operation needs long time, the server
> is timing out while the data channel is working.
It may not be happening on the server end. In fact, it does not make sense
for an FTP server to timeout the control connection belonging to an active
transfer, as it knows that client is not idle.
> Can I send some keep alive command somehow while the
> datachannel is uploading?
Not reliably, no. There is nothing in the FTP spec that provides for such a
keepalive. Some third-party FTP clients have an option to send a NOOP or
other command over the control connection during a transfer. But that is
not standard behavior, and not all FTP servers will recognize/allow it at
all, and others will simply cache the commands until after the transfer is
finished.
Gambit
