425 Can't build data connection:bind error: Address in use

Question

We are getting intermittent 425 "bind error" responses from a corporate partner's FTP server:

425 Can't build data connection:bind error: Address already in use.

The stack traces indicate that this error occurs with a variety of code paths in our client, including both puts and gets.

However, all of these stack traces end with FTPControlSocket.validateReply() being called by either initPut() or initGet() in FTPClient.

Our (active) FTP command sequence just prior to these errors is: PORT then RETR, or PORT then STOR. The PORT commands always succeed. The RETR and STOR intermittently fail with this 425/bind error.

I ran across this post which sounds similar: http://www.enterprisedt.com/forums/viewtopic.php?p=8461

Bruce's response in that post suggests that rapidly transferring many small files can overwhelm the O/S handling of port open/close efforts.

I'd like to confirm that Bruce meant that the FTP Server (rather than the client) is what is getting overwhelmed.

If that is true, then Bruce's workaround suggests slowing down the client requests. Our client does attempt to transfer many small files back and forth (1-2 per second). I suspect that our partner's FTP server is heavily loaded, and perhaps a bit dated. Might there be other server (or server host) configuration issues that could cause this? If so, perhaps we can make some recommendation to our partner's IT staff.

I'd also appreciate confirmation of my understanding about FTP server responses to a PORT command: the server will return success as long as the PORT arguments are reasonable, and the server postpones actually making a data connection to that host/port until the RETR or STOR command is received.

We are using edtFTPj/PRO 3.0.1 (but plan to update to a new version soon). Thanks.

Answer 1

Most likely this is a server problem (it is certainly an error provided by the server), and yes, the server doesn't attempt to connect until STOR or RETR.

You could increase the number of file descriptors available to the server process (esp if it is on Unix) - see the ulimit command. You can also reduce the time it takes for sockets to be freed up (the amount of time they spend in the TIME_WAIT state).

You could also slow down the rate of transfers, e.g. sleep in between them for a few seconds.

Answer 2

Since we don't have any control over our partner's FTP server, all we can do is make recommendations. Thanks for some specific suggestions.

We only have control over our client, and it sounds like introducing delays between file transfers is about all we can do. I suppose we could also check explicitly for this 425 error with "bind error" in the message, and retry (perhaps after a delay) some limited number of times.

Thanks for the quick response, Bruce, and for addressing each of my questions. I really appreciate it.