Noop

Certain FTP servers require NOOP commands to be sent periodically to keep the connection alive. FluentFTP supports sending a NOOP command at the specified interval.

Please note that if you turn on the NOOP feature, SSL Buffering on the control connection will be forcibly turned off. The data connection will still have SSL Buffering without issues.

All credits for the development and testing of our excellent NOOP support go to Michael Stiemke and Carl Krig.

Settings

• Config.NoopInterval - Time to wait (in milliseconds) between sending NOOP commands to keep the control socket alive during long file transfers. Setting this interval too low will have a negative impact on performance. Setting this interval to 0 disables NOOP commands altogether. Increase this setting if you are getting timeouts during file transfers. See FAQ entry below for suggested values. Default: 0 (Disabled). Do not set this to be less than 15 seconds.

What settings are required to enable NOOP support?

Currently if you need to reliably use NOOPs, you need to either turn off encryption for best results or try .NET Framework, which will sometimes glitch with v40+.

Also, your experience will vary depending on the server type and its configuration.

What is the current status of NOOP support?

2022/09/29 with release v41:

proftpd

Framework	NOOP plain text	NOOP encrypted
.NET 6.0+	works	works
.NET Framework 4.7+	works	works

vsftpd

Framework	NOOP plain text	NOOP encrypted
.NET 6.0+	works	works
.NET Framework 4.7+	works	works

Other servers: Currently Unknown.

See the full issue for more info.

If NOOP handling fails, what does it result in?

The incorrect handling of 200... responses to the NOOP command will typically cause the next command in a sequence to fail. The RETR or STOR command that was using the NOOP commands to keep it alive will typically end successfully.

Why do we need to send NOOP commands?

NOOP commands are a way to keep-alive the FTP control connection. Failure to send these periodically results in Timed out trying to read data from the socket stream! errors.

Being able to solve problems where your control connection is being dropped because of a too long idle state really depends on many factors. There are a lot of places in between the client and server where this can happen, it can happen on the server too.

The servers configuration might discourage keep alives, depending on its configuration.

The way a server reacts to keep alive tests (such as NOOP) will differ not only by its configuration - different servers are programmed differently.

Last but not least, we see different behaviour on the client side, depending on encryption, ssl protocol and the underlying .NET frameworks.

References:

1. NOOP handling of different servers
2. Keep Alive Techniques in general (proftpd) (here, read the section on FTP Keep Alive in detail).

How do I set the NoopInterval property?

It seems that the AzureVM router or firewall does not respect TCP Keep-Alive on the control socket (port 21). When large file transfers runs on data socket (port 20 or passive) there is no traffic on the control socket and it breaks for after ~280s (perhaps 240s). Before mentioned workaround setting EnableThreadSafeDataConnections = true simply caused the exception from the broken connection to be discarded, pretending all was fine and opening a new control socket.

The NOOP command responds something like '200 NOOP command successful.' or '200 NOOP: data transfer in progress' and is typically used by a FTP UI client to keep the control socket alive in-between commands, so it is a good candidate for using during long-running command executions (i.e. RETR/STOR). However the https://tools.ietf.org/html/rfc959 neither suggests that nor against it.

Indeed, googling shows that it has been proven in battle, with some odd complaints (see link to smartftp.com some comments back) that it could potentially cause file transfers to abort (remains to be proven) or make FTP servers behave strangely like not responding 200 (that is what I can see from IIS) or respond at the end of the file transfer (have no such evidence, but pull request attempted to cope with that in a rudimentary manner).

Suggested usage for NoopInterval (in milliseconds) from past experience;

• 0 (default) if you can get away with it do not fiddle with it, keeping in mind that sending commands during command execution might not be by the book for all FTP server implementations out there
• firewall timeout divided by 2, if you can determine the timeout by transferring files 10MB, 50MB, 100MB, 500MB, 1GB, 5GB
• 30000 or 45000 or 90000 (corresponding to 30s, 45s or 90s) would make sense
• not something like 1000 or 5000, that would be nonsensical because any socket must survive 5s silence, problem should be sought elsewhere like in the firewall

References:

1. Original author comments from the PR that implemented Noop