Unix Programming - Why does recv() succeed on a broken connection?

Author

Why does recv() succeed on a broken connection?

Just Another Victim of the Ambient Morality

2004-09-21, 4:00 am

I have a TCP (connection-oriented) socket that was once connected but
has had that connection terminated by the other party. Now, select()
returns saying that my socket is ready for reading but a call to recv() (or
read()) will return 0 instead of -1, like I had expected. Why is this?
send() (or write()) returns -1, allowing me to know that the connection has
been terminated, so why doesn't recv()? recv() obviously knows that the
connection has been cut because it knows that the call won't block (select()
returned, after all) and that there is no data in the input buffer.

I could just check for 0 bytes and assume that that indicates a broken
connection but I think it would have been more consistent to return -1, like
send() does. Does anyone have any thoughts or insights into this situation?
Am I not understanding something here?
Thank you for your input...

Barry Margolin

2004-09-21, 4:00 am

In article
<bfN3d.107274$Q7D.104298@twister01.bloor.is.net.cable.rogers.com>,
"Just Another Victim of the Ambient Morality" <ihatespam@rogers.com>
wrote:

> I have a TCP (connection-oriented) socket that was once connected but
> has had that connection terminated by the other party. Now, select()
> returns saying that my socket is ready for reading but a call to recv() (or
> read()) will return 0 instead of -1, like I had expected. Why is this?

If the connection was terminated normally, you get EOF when you try to
read from it, not an error. EOF is indicated by read()/recv() returning
0.

> send() (or write()) returns -1, allowing me to know that the connection has
> been terminated, so why doesn't recv()? recv() obviously knows that the
> connection has been cut because it knows that the call won't block (select()
> returned, after all) and that there is no data in the input buffer.
>
> I could just check for 0 bytes and assume that that indicates a broken
> connection but I think it would have been more consistent to return -1, like
> send() does. Does anyone have any thoughts or insights into this situation?
> Am I not understanding something here?
> Thank you for your input...

You should always be checking for 0 bytes, since that means EOF on any
type of file descriptor.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Andrei Voropaev

2004-09-21, 9:04 am

On 2004-09-21, Just Another Victim of the Ambient Morality <ihatespam@rogers.com> wrote:
> I have a TCP (connection-oriented) socket that was once connected but
> has had that connection terminated by the other party. Now, select()
> returns saying that my socket is ready for reading but a call to recv() (or
> read()) will return 0 instead of -1, like I had expected. Why is this?
> send() (or write()) returns -1, allowing me to know that the connection has
> been terminated, so why doesn't recv()? recv() obviously knows that the
> connection has been cut because it knows that the call won't block (select()
> returned, after all) and that there is no data in the input buffer.

I guess, you misunderstand the error and EOF. Any time when remote side
terminates (not the OS crash but application crash/close) then remote OS
passes EOF to you. It is not an error. OS does not care if application
has crashed or simply decided to exit. So no error passing. That's what
you get when you call recv. 0 indicates EOF. Really, does it make any
difference to you why remote has closed connection? The most important
thing is that connection was closed.

Now, things are completely different with 'send'. Send attempts to pass
data to remote side. And if remote side has already closed connection
then it is an error to send that data there. But in reality things are
more complecated. Connection can be "half-closed". For example remote
side finished sending and to indicate that, it does "shutdown send". In
this case you still can send your data. So your OS will keep sending
data event if it received EOF from remote side. Your 'send' shall
return error only if remote side returned Connection Reset. (Of course
if you specified MSG_NOSIGNAL flag)

>
> I could just check for 0 bytes and assume that that indicates a broken
> connection but I think it would have been more consistent to return -1, like
> send() does. Does anyone have any thoughts or insights into this situation?
> Am I not understanding something here?
> Thank you for your input...

To summarise. When you read data you get an indication that remote side
has closed the connection. It is not an error, just a mark saying that
there'll be no more data coming. When you send data you get back an
error when remote side refuses to accept more data.

Andrei

Sponsored Links