0

some code of mine is using a queue to upload files to an FTP server. When files get queued, a connection attempt is made and, if successful, files are uploaded. Once the queue is empty it disconnects the server. Pretty straightforward.

The queue can, and will, be accessed by multiple threads. In some cases the queue completes, thus disconnects, but then new files get queued immediately afterwards, and a new Connection\Upload cycle starts. In some extreme cases it uploads only 1 file between connection and disconnection, only to repeat the process for several minutes or even hours.

I find this unacceptable and will change the code accordingly, but I wonder:

Question

Say we'd ignore the obvious waste of time & resources (all those dis/connections are unnecessary, to say the least).

Does the FTP server mind? Is such a behavior frowned upon, is it rude? Could it be even seen as a borderline flooding or hammering of some sort?

r41n
  • 103
  • 2

2 Answers2

1

Depends on the server admin. Email them and ask about the AUP. Ideally you'd have a tuneable reconnect delay per server.

I wouldn't go so far as to say this behavior is bad; that really depends on the role of the FTP server and the overall software platform architecture.

Consider moving away from FTP, if only to FTPS, but preferably SFTP. Password-based automatic login has been unrecommended for a very long time.

Andrew Domaszek
  • 5,163
  • 1
  • 15
  • 27
  • +1. I'd love to drop those passwords, but it's probably not going to happen anytime soon. – r41n Mar 31 '17 at 13:01
0

Generally no. I help run a site like this and my biggest annoyances are:

  1. People that log in over and over multiple times/second. Usually this is from a script on the client-side that someone forgot to put a "sleep" in.
  2. People that never log out so I can't drain my load balancers properly.
  3. People that transfer one file per session repeatedly and launch 100s to 1000s of connections at the same time.
  4. People that transfer extremely large files that could be broken up into smaller batches.
  5. People that connect to our site and expect it to be 100% reliable for old protocols like FTP.

Also keep in mind that if you are connecting to a busy site a lot of folks schedule their jobs to run on the 5s, 15s, etc. - for example 1:00, 1:05, 1:10, 1:15. If you really want to be a nice consumer please avoid times that are on the 5s or 0s. Not only are you helping out the site admin, you will probably get better performance. Some suggestions for scheduling:

  • run your jobs ad-hoc (assuming this won't always be on 0s and 5s)
  • run jobs on minutes 2-4, 7-9. This gives a little buffer for jobs that have started on the 0s and 5s to complete.
  • put a randomized sleep in your scheduled job so it is not always hitting the file server at the same time.
  • please do not schedule your job to run more than once every 5 minutes if you can help it.
montjoy
  • 195
  • 7