INDY FTP server not 226-ing


(Been a few years since my last post…)

Hoping that someone with more Indy FTP server experience than I can shed some light on this puzzle.

Delphi2006 (though not relevant)
Indy 10.1.5

I’m using a TIdFTPServer to receive files FTPed by a networked currency counter.

It works okay - except for being slow (compared to Filezilla).

The slowness is because after every file is uploaded - immediately after the last data packet - there is a 300ms delay.

The counter logs in and establishes an FTP connection separately for each file, and there may be several hundred files, about 30k size each, in a batch. The accumulated 300ms delays comprise the majority of the overall transfer time.

No such delay occurs using Filezilla as the FTP server - Filezilla sends a 226 ‘ok’ response immediately after the last data packet.

Instead of sending the 226, Indy waits for about 300ms and then sends a ‘TCP retransmission’ and never sends the 226. The counter then proceeds as per normal with the next command (RNFR to start a file rename).

Apart from that difference, Wireshark captures between Filezilla and Indy appear identical.

Having read up on the FTP protocol, my assumption is that the counter isn’t closing the data connection (which wouldn’t show up in Wireshark) and Indy times out the connection after 300ms (though that seems a very short timeout). But if that was the case, how does Filezilla proceed without a hitch?

I did try the latest Indy, 10.6.2, but that made only a very minor improvement to the overall time. (Sent to the client remotely and didn’t do any debugging or wireshark captures.) (And then reverted to the original Indy as the next time I started BDS it complained about a missing Indy file - even though it had just recompiled the app using 10.6.2.)

If I can’t get this solved with Indy I’m considering changing to ICS, being another freeware FTP alternative.



Hi Adam,

Have you tried disabling the Nagle algorithm? Not sure if that will solve your problem… but it does cause delays in certain situations.

G’day Geoffrey,

Thanks. Having done some Googling that does seem a possibility.

The following Microsoft article does seem to describe exactly what happens and what I see in Wireshark:

I’ve asked the client to add a TCP_NODELAY environment variable and test.

If that works I’ll add a SetEnvironmentVariable(‘TCP_NODELAY’,‘YES’) to the app.