When I connect with TIdLPR or TIdRSH, I get a EIdSocketException saying "Socket Error # 10048 Address already in use." Why?
|Previous Top Next|
The reason you get an address already in use is because after a local port has been used, it goes into a FD_WAIT state. This FD_WAIT state is intended to give the stack enough time to negotiate the final TCP/IP connection close sequence without interference from other connections as well as preventing the close sequence from interfering with other connections. While in FD_WAIT, you can not use that particular local port and address combination.
For TIdLPR and TIdRSH, we force the client to bind to a local port within a specific range before connecting to a server because these protocols require the client to use specific local port ranges when making a connection to a server. This is done with the TIdTCPClient.BoundPortMin and TIdTCPClient.BoundPortMax properties.
Usually, if you do this with a specific IP address while a local port is in FD_WAIT state, the bind fails and Indy will then try to bind to the next port. Unfortunately, when using the wildcard IP address (0.0.0.0), the bind will succeed while a port is in a FD_WAIT state but when you connect, you get an "Address already in use" error.
The only workarounds available are:
|•||Wait a minute for the local port to get out of FD_WAIT state.|
|•||Set the TIdTCPClient.BoundIP property to the to the machine's current local IP address. This workaround can be problematic if a machine has more than one local IP address and you do not know which one to use.|
For most clients, the best practice is to let the stack select any available local port because most servers do not care what local port the client is using and because of the issue we mentioned earlier. Do not use the TIdTCPClient.BoundPort, TIdTCPClient.BoundPortMax, and TIdTCPClient.BoundPortMax properties unless you have a very compelling reason to do so.