Socket 'recv' returns 0

bill_nimmo · 11-03-2014, 04:41 PM

Hello All,

I realize this topic has been addressed before. From what I have read, a socket 'recv' on the server side returns 0 when the client has closed the connection. I am experiencing this situation in cases where it probably shouldnt happen.

Quick snapshot of my project: all code is written in 'c'. The client platforms can be solaris or linux. The server platform is linux. Its a fairly simple TCP/IP comms set up. There are 1 to about 30 clients that can attempt to connect at one time to my server.

The client-to-server connection can go over many hops and many different routers. In fact, doing a traceroute from server to some clients can take several minutes to reach the destination. Lots of security in between.

The server is single threaded, and handling many client requests at one time. Many times, the connect occurs but when the server goes to do a socket 'recv', there are zero bytes.

I dont understand the internal workings of TCP/IP, but I thought delivery was guaranteed. If a client connects and sends a packet (these packets are fairly small..less than 1000 bytes) then does a disconnect gracefully, is there a situation where the packet gets lost somewhere in transition? Is it a timing issue (again, tracerouting shows many times where it takes several minutes to get through to the destination).

Any ideas, suggestions, critiques would be welcome.

thanks,
Bill

berndbausch · 11-04-2014, 04:35 AM

Quote:

Originally Posted by bill_nimmo

Hello All,

I realize this topic has been addressed before. From what I have read, a socket 'recv' on the server side returns 0 when the client has closed the connection. I am experiencing this situation in cases where it probably shouldnt happen.

While I may have roughly the same level of networking skills as you, may I suggest tracing? On the server, run

Code:

tcpdump -i <network interface> port <whatever port you use>

Output can be written to a file using the -w option and then analyzed later, using the -r option. Or use wireshark if you have a GUI on the server. You would have to look for a packet with the FIN bit set in the header.

Here are my notes about establishing and closing a connection, summarized from http://tangentsoft.net/wskfaq/articl...ging-tcp.html:

Code:

Client					Server
	CLOSED			CLOSED
connect()				listen()
	send SYN		LISTEN
	SYN_SENT
				send SYN; ACK
				SYN_RCVD
	send ACK
	ESTABLISHED
				send nothing
				ESTABLISHED

-------------  data transfer  ------------

close()
	send FIN
	FIN_WAIT_1
				send ACK
				CLOSE_WAIT
	send nothing
	FIN_WAIT_2
					close()
				send FIN
				LAST_ACK
	send ACK
	TIME_WAIT
				send nothing
				CLOSED
	<timeout>
	CLOSED

where CLOSED, TIME_WAIT, FIN_WAIT and so on are socket states which you can see with netstat.

bill_nimmo · 11-04-2014, 10:10 AM

Thank you very much for the reply. I took your advice and used tcpdump to monitor input (tcpdump -X -vvv port PORTNUM). Though I dont completely understand the output, I gather that its showing me the IP and some incomprensible header information.

In my C program, I am capturing what I think is the source/client IP during the accept command and printing it out. I am also printing out (via SEEK) what is in the header of the message on the socket. I am simultaneously running a tcp on that port number.

What I am seeing in the output of the C program doesnt always align with what is output in the C program. There is not a one to one correlation. (I am capturing output of both tcpdump and C debugging and matching the IPs from the outputs). I guess there could be some latency between the time the C program reads off the port to the time it actually arrives (shown in the tcpdump).

I dont have complete trust that what I am seeing in the client.sin_addr in the C program is accurate. I am 'assuming' tcpdump is the more accurate representation. But how could they be so far off?

any ideas?>

thanks,
Bill