bind : address alread in use .
eyal haviv
I wrote a tcp/ip Client-server application which run on SolarisOS5 .
The problem is : if I stop the client and then try to activate the
client again ,
I get : ' bind address already in use ' and only after several minutes I
succeeded
to establish the connection again .
Why does it happens ? and How can fix it , so the client could start
immediately
after he was stooped .
Please replay to : ey...@security7.com
Jon C. Snader
Your client is in TIME-WAIT state, waiting for any lost packets from the
connection to leave the network, and remembering state in case its ACK
to the server's FIN gets lost and the server resends the FIN.
Why are you binding a particular port in the client? Unless you have a
particular need to do so, you should should merely connect to the server
(don't call bind at all) and let the kernel choose the local port for
you. That way, when you restart the client, the kernel will choose
another port and you won't have to wait for the TIME-WAIT state to
expire.
In the server, you have to bind the well-known port, of course. In this
case you should set the SO_REUSEADDR socket option to avoid the
problem. Note that you should *not* do this in the client as you could
then have a reincarnation of the old connection while packets from the
first connection are still in the network.
Jon Snader
Lon Stowell
>This is a multi-part message in MIME format.
[not any more. It wiould be nice if you disabled MIME in
your newsreader]
>Hi .
>
>I wrote a tcp/ip Client-server application which run on SolarisOS5 .
>The problem is : if I stop the client and then try to activate the
>client again ,
>I get : ' bind address already in use ' and only after several minutes I
>succeeded
>to establish the connection again .
The socket is almost certainly in TIME_WAIT. This is proper
behavior. You can check with netstat -a.
Depending on your version of Solaris, you can tune the timer for
this down a bit in /etc/system. If you have access to the
sunsolve site, look for tuning tips for webservers, as this
can be a problem for some of them as well.
You will be tuning /dev/tcp, you can see what all the
variables are with 'ndd -get /dev/tcp \?'.
You may also want to look up SO_REUSEADDR in your favorite
unix network programming reference.
Rick Jones
: behavior. You can check with netstat -a.
: Depending on your version of Solaris, you can tune the timer for
: this down a bit in /etc/system. If you have access to the
: sunsolve site, look for tuning tips for webservers, as this can
: be a problem for some of them as well.
: You will be tuning /dev/tcp, you can see what all the
: variables are with 'ndd -get /dev/tcp \?'.
: You may also want to look up SO_REUSEADDR in your favorite
: unix network programming reference.
Given that any TCP implementation worth the CPU cycles it consumes can
handle thousands and thousands of TIME_WAIT state connections, and
given that TIME_WAIT is an integral part of the TCP's correctness
algorithms, it is probably best to go the SO_REUSEADDR path instead of
crippling a TCP's ability to protect against data corruption by
shrinking the TIME_WAIT state length.
Be suspicious of any site that suggests shrinking TIME_WAIT...
rick jones
--
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...