Race condition with multi-threaded application using PASSIVE

Question

I use your FTP library in conjunction with a homegrown Rollout tool to upload files to an Akamai download server. For the most part, your FTP library has been a lifesaver. In fact, about the only problem I

Answer 1

Anyone have thoughts on this topic?

Answer 2

edtFTPnet isn't thread safe (and doesn't claim to be), so each thread should use a separate FTP connection - or else you could maintain a pool of connections that access is synchronized to. If you are doing this, you shouldn't get any problems like you describe.

If multiple threads are sharing the same connection you'll certainly get weird problems.

Answer 3

Let me be clear -- each thread is using its own, separate FTP connection, yet this race condition exists. Please re-read my first post for a description of what's happening.

When reading that post, please understand that when I say "multiple threads can be seen accessing this method at the same time", I mean multiple threads, each associated with its own, separate FTP connection object.

Answer 4

In PASV mode, the server is sending the client the port number to connect to (that the server will be listening on). It actually sounds like a bug in the FTP server - under no circumstances should separate connections be sent the same port number.

It looks like the server doesn't mark the port as being used until the client has actually made the connection to the server, rather than when the port number has been handed out (it should do the latter). Or perhaps it doesn't take into account multiple connections from the same IP address.

Your fix stops the server doing this, as no other connection in the same process can connect in PASV mode until the client has connected to the server socket on the supplied port.

Of course this doesn't happen in active mode as the FTP client is handing out the port numbers.

We're undecided at this point how best to deal with this. There's no reason in the FTP RFC why clients shouldn't do what you are doing, i.e. have multiple connections in different threads. It seems to be a buggy server that you've had to work around.

One possibility might be to introduce a flag called SynchronizePassiveConnections or something like that - this would mean the behaviour can be enabled if required. We'll give it some thought - and any further comments of yours are very welcome. Thanks for your efforts in explaining the problem.

Answer 5

That is an excellent commentary on the problem. I too suspect that this is a bug in the server FTP code, as it seems to be making improper assumptions about the port numbers it hands out. As you

Answer 6

Any update on adding SynchronizePassiveConnections? I am now using your PRO version (5.0.2, without source code) and, therefore, will no longer be able to customize your code with such a method. Yes, using ACTIVE does work for the cases where I can use ACTIVE, but I'd like the option of PASV mode.

I'd be happy to send you my customized version if that helps speed up the implementation.

Answer 7

this had slipped off the radar a little. if you would like to send your version to us (support at enterprisedt dot com) we'll get a patch out to you to try

Answer 8

I've emailed the code and I'd really appreciate it if you could incorporate this into your next release.

Thanks!

Answer 9

Will do.

Answer 10

This will be in 5.0.4, to be released soon (within a few days)