Thursday, April 9, 2015

Images for the Bind Error situation.


The above picture shows a server running, and in a terminal, this command has been executed :

netstat -a -tulpn

and it shows the process id and name of the processes and the ports they are using and their states, then it shows the type of connection - udp,tcp and all.

Now, below are two images to show how server was close unexpectedly using Ctrl+C ( you should actually use Ctrl+Z ) and client is also close unexpectedly.



Now, here, I closed server first, then the client. Both in an unexpected manner using Ctrl+C.

If you use the netstat command, you will see this :


I used grep with the port number, to get processes that have the port number. Actually, now, the port number is being used by the kernel and not by any process and if you try the server program now, you will get bind error. [ Error occurs only if the netstat command shows "TIME_WAIT" as the state of the socket associated with port 6700 (the one on left). And note that socket associated with 6700 occurs at the left (local port) and another port number 36594 on the right(remote port), which is of the client, here.]

But if you close the client first, then the server. Both in an unexpected manner, and then use netstat command, you will see this :


Here, the socket associated with port 36595 (the one on left ) is in TIME_WAIT state and socket with port 6700 does not happen to be in that state. Now, if you run server, listening at port 6700, you won't get bind errors.

And this happens in TCP, where there are states like "TIME_WAIT"  "CLOSED" "FIN_WAIT" and stuff in the connection termination phase. I don't think there is any possibility of bind error in UDP, due to unexpected closing of the server / client. Thought it may occur due to some other fault.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.