Hello ..
>Problems with NOOP command
Servers that do not support will act strangely (e.g. send the NOOP reply at the end of the transfer, don't reply at all, transfer aborts because server doesn't expect a NOOP command, etc).
>Benefit of NOOP during transfer
The only reason you would send NOOP commands during a data transfer is when you are connected through a firewall which is not aware that there is still a data transfer in progress. This was sometimes the case with 1st generation firewalls which didn't inspect the data on the application layer level. I'm a bit surprised that such products still exists as you will end up with numerous other problems whenever you use a protocol which needs a shared state between two or more connections. E.g. FTP protocol: control connection / data connection.
>Resume
There is no general problem with resume unless - as you mentioned - your FTP server triggers some action whenever a transfer finishes, regardless if it's successful or not. However there is no guaruantee that your transfer will finnish the first time. What if it breaks for other reasons?
Depending on your interest and motivation to do some testing we are willing to implement this feature for you within a couple of days.
Regards,
Mat
There are definitely appliances out there that don't do application level monitoring. The group running this one is recommending that keep-alives (during transfer) are the standard way of overcoming the issue, and won't turn on application aware monitoring because of the load it will add to the box.
I tried using the transfer queue and saw the ftp fail as expected. The client then continually retried to establish the transfer, but was unsuccessful. In Wireshark I can see the MDTM command from the client and I can see the server respond with what I assume is a count of bytes transferred thus far, but after that the transfer does not restart for some reason (There are FTP packets exchanged ending with a Response: 500 File transfer failed). So in this case the NOOP command during transfer does the trick, but the resume function does not help.
I understand your point about a transfer failing for some other reason, and so I will try to further investigate what is going wrong with the resume feature, but it seems best to have the option to use both features.
I'd be happy to test out the keep-alive during transfer feature for you if you developed it. (To be up-front - I won't be purchasing the client, but I would mention it to groups that need to carry out large ftp uploads and who want/need a client with this feature).
