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>
 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