Indy FTP Server Error Question (Could not bind socket)

[snorkel]

Yep, I found that out with a bit of googling :-)

I don't think the error is coming from the passive data connections but from new client connections and probably related to the SO_REUSEADDR being used on all binds.
Shouldn't the SO_REUSEADDR just be used on the listening sockets for the server?

It appears that the FTP server  applies SO_REUSEADDR to all sockets if the reuseSocket param is set to rsTrue?

Maybe I should try setting it to rsFalse and see what happens.  The worst that could happen is the main server port might not be available for a few minutes right if I shut it down and then start it back up right away.

[snorkel]

ok, what I did as a test was to disable socket reuse in the ftp server properties and then do this in the bind procedure in IDSocketHandle:

  if (self.Port = 21) or (port = 10021) then
     SetSockOpt(Id_SOL_SOCKET, Id_SO_REUSEADDR, Id_SO_True) else
  SetSockOpt(Id_SOL_SOCKET, Id_SO_REUSEADDR, LValue);

So if the port is one of the listening ports I enable the socket reuse so the service can start up again fast and then all other binds have it disabled via the property setting.
The server is not that busy that I would exhaust ports that are not in a time_wait state.

[Remy Lebeau]

I don't think the error is coming from the passive data connections but from new client connections

bind() is not called on new client connections, only on data transfer connections.

and probably related to the SO_REUSEADDR being used on all binds.

SO_REUSEADDR is only enabled if:

1. ReuseSocket is rsTrue.

2. ReuseSocket is rsOSDependent (the default) and GOSType is otUnix (which it is not in your case).

ENABLING SO_REUSEADDR would not be causing your bind errors. DISABLING it might.

Shouldn't the SO_REUSEADDR just be used on the listening sockets for the server?

In FTP, bind() is used for both listening and connecting sockets.  Inbound passive-mode transfer sockets are bound to the passive port range, or to the server's DefaultDataPort if no range is specified.  Outbound active-mode transfer sockets are bound to the DefaultDataPort.

It appears that the FTP server  applies SO_REUSEADDR to all sockets if the reuseSocket param is set to rsTrue?

Yes (on a per-socket basis).

Maybe I should try setting it to rsFalse and see what happens.

It was not set to rsTrue by default to begin with.  So you had to have set it to rsTrue at some point.

The worst that could happen is the main server port might not be available for a few minutes right if I shut it down and then start it back up right away.

Or, the server ports might not be available for a few minutes after each data transfer.

ok, what I did as a test was to disable socket reuse in the ftp server properties and then do this in the bind procedure in IDSocketHandle:

You should not be modifying Indy's source code like that.  TIdFTPServer has published OnBeforeBind and OnDataPortBeforeBind events.  The first event is for the main listening sockets that clients connect to for commands, the second event is for the data transfer sockets.

[snorkel]

Hi Remy,
Thanks for the Advice :-)
yes, you are correct, I must have set the ReuseSockets to true at some point.  I don't remember why I enabled it, it was almost a year ago.

I was already in the source code, so I just added that as a quick test, I already modified my copies source code by adding after put and after get events.

The mainframe people already sent their files for the morning run with that quick mod and no bind errors, granted it was happening like once a week.

I will use the events if this works.  because the bind error happens so rarely I was just guessing that it must be picking up a socket that is in a wait state, but still connected and I was reading that if SO_REUSEADDR is set it is possible to get a socket that is in that wait state and still connected and hence the error address and port already in use.

There is also a SFTP server running on this particular server plus lots of Python scripts that are using Paramiko SFTP client to upload and get files. 

It is definitely called when the listening sockets are created, so now with that slight mod only the listening sockets on port 21 and 10021 have  SO_REUSEADDR.

[snorkel]

Just following up.
Been almost two weeks and not a single socket binding error since I made that change to only do the socket reuse for the listening sockets.

I don't remember why I enabled the socket reuse in the first place, but I am guessing it's because the service would not start up right way if it was restarted because the
listening socket was still in a wait state.