tags:

views:

106

answers:

5

I am having an application which established a socket connection on a port number 5005 with another device(hardware device with a web server).

Now if my hardware device disconnects then i loose connection with the device.

  1. Does this mean that the socket i was using until now becomes invalid.

  2. Do i get any special message like null character or something when this disconnect happens.

  3. If the socket connection i was having became invalid then why doesnt the recv() socket function throw and SOCKET_ERROR. Instead why do i receive data of 0 length.

Thanks

+8  A: 

When recv returns a value of 0 that means the connection has been closed.

See the recv man page:

These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown.

In answer to question #1, yes the socket is now invalid. You must create a new socket and connection for further communications. Edit Now as valdo pointed out below, there is also the possibility of having a half-closed TCP connection in which you can't receive any more but you can keep writing to the socket until you've finished sending your data. See this article for more details: TCP Half-Close. It doesn't sound like you have this situation though.

In answer to question #2, there are basically two ways to detect a closed socket. This assumes that the socket went through an orderly shutdown, meaning the peer called either shutdown or close.

The first method is to read from the socket in which case you get a return value of 0. The other method is to write to the socket, which will cause the SIG_PIPE signal to be thrown indicating a broken pipe.

In order to avoid the signal, you can set the MSG_NOSIGNAL socket option in which case send would return -1 and set errno to EPIPE.

Robert S. Barnes
So what i need to do is if i get a return value of 0 then i need to close that socket and open another socket right?
ckv
@cvk - Correct.
Robert S. Barnes
@Robert - Thanks.
ckv
Why did someone mark this answer down?
Robert S. Barnes
+1  A: 

If recv returns 0 this means that the peer has closed the socket.

recv won't throw because its a C function.

If there's an error recv will return -1. In which case your application has to check the type of error. Note that a return of -1 does not imply that the peer has closed it's socket.

sashang
+1  A: 

Given that you're talking to a web server, I'll assume you're using TCP sockets.

To answer:

  1. Sockets don't become invalid due to a disconnect; they simply go into a disconnected state. It's still safe to call socket operations on them.

  2. You don't get any special messages when the disconnect occurs. If you call recv() in a blocking fashion, it will return when disconnected, and the number of bytes returned from the call won't match the number of bytes you asked for.

  3. There isn't really an answer to this - it's how the socket API was implemented originally, and we're stuck with that implementation as everyone implements Berkley Sockets.

Blair Holloway
+2  A: 

I suppose you're using TCP to communicate with your device.

  1. The socket itself is still "valid", however the the connection was lost.

  2. You get a return value of 0 for recv() when the connection was closed by the other host (wether this disconnection was graceful or not doesn't matter)

  3. socket functions are like C functions: they don't throw because they can be used in C programs, where exceptions do not exist.

ereOn
+5  A: 

Agree with Robert S. Barnes. Except the claim that the socket is now "invalid".

It's still valid. You can use it. You can even send data to the peer. The only thing you can't do with it is call recv.

valdo
+1 Right, I forgot about the possibility of a half-close. I'll update my answer.
Robert S. Barnes
Wanted to point out that this depends on whether or not the peer called `close`, or did a half-close by calling `shutdown` with the `SHUT_WR` flag. See the `shutdown` manpage: http://www.kernel.org/doc/man-pages/online/pages/man2/shutdown.2.html
Robert S. Barnes