The implementation returning EADDRINUSE is by design, you can learn about it by searching for TCP TIME_WAIT state; 
random hits:
http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
http://www.microhowto.info/howto/listen_on_a_tcp_port_with_connections_in_the_time_wait_state.html

Code similar to the following may stop getting EADDRINUSE:


int yes = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));


On Apr 16, 2014, at 9:36 PM, Robert Murrell <community-noreply@qnx.com<mailto:community-noreply@qnx.com>>;
 wrote:

I am developing under QNX 6.5.0 an embedded system with a minimal QNX install.  Our application has a built in web 
server listening on port 80 (its in a blocking accept() call).  If the program terminates, either by a SIGTERM or crash,
 a boot program will restart the program.  When the program restarts, the bind() fails with EADDRINUSE.  Whats more, 
when dhcp.client gets an IP address, it call a custom dhcp-up program I wrote.  This program opens a socket, connects to
 http://localhost:80, and sends a specially crafted HTTP GET command to signal our application that it has an IP address
.  If this happens when the TCP port is in this busy condition. the connect() is successful and so is the send().  But 
the call to recv() blocks forever, locking up dhcp-up.  I know I can make dhcp-up a little more robust to time out in 
this condition, but I did not expect the connect() to pass.

I was under the impression that QNX automatically cleans up after a terminated program by releasing all its allocated 
resources.  Apparently this does not include in-use TCP ports.  An internet search shows this to be a fairly common 
problem with TCP/IP stacks and there are various tools available to reset the stack.  So my question is, does QNX have a
 mechanism to remedy this situation?  I have tested killing io-pkt-v4, restarting it, and then remounting the Ethernet 
drivers.  This works, but I would like to know if there is something a little more elegant to fix this.




_______________________________________________

Technology
http://community.qnx.com/sf/go/post109933
To cancel your subscription to this discussion, please e-mail technology-networking-unsubscribe@community.qnx.com

An Internet search on CLOSE_WAIT shows that there is no remedy for this condition.  When QNX cleans up an abnormally-
terminated process, it would be nice if it called shutdown() on any open sockets on behalf of the process.