send() doesn't report error if server is dead

[chimney]

Hey,
i'm a newbie with C and Sockets.
My Client program has the following code:
...
if ( send (sockfd, string_to_send, strlen(string_to_send), 0) <= 0 ) {
perror ("send");
return (-1);
}
...

But if the Server is down - i don't get any messages.
What is wrong here?

Thank you,

[RobSeace]

Well, typically, send() doesn't fail until sometime after the first
time you send a message after the remote side goes away...
Often, the second send(), but maybe not until much later, if it
can't tell right away that the remote is really gone (ie: it thinks
it's just temporary network wackiness, which might clear up)...
But, assuming it can tell right away, then that first send() will
notice the failure, so that your second send() will actually fail
so that you can see it...

The reason the first one can't notify you of the failure, is because
send() doesn't really wait around and try to actually send the data
when you call it... It simply copies it to your send queue, and
returns; then, your system's TCP/IP stack does the actual
sending of the data, sometime after that... And, it's not until THAT
point that it can detect a problem sending... But, once it does, it
should then cause any future send()'s to fail...

[chimney]

Hi,
thanks for quick reply. Actually i need this as a part of my 'Operating Systems' course assignment. :roll: So i'd like to know whether there's an elegant solution to this. Because in my project i have a client and server which communicate, if client sends something to server and doesn't get a reply - he would just stuck.

[RobSeace]

Typically, people put a timeout on all I/O, and if it times out, the
connection is just assumed to be dead... So, in your case, it
sounds like for every message you send, you expect an
immediate reply, yes? If so, then your read()/recv() would
time out before a reply comes in, and that would be your signal
that the other side has disappeared...

If you don't use a timeout, the read()/recv() should still eventually
fail, if the remote is gone for good... However, it's likely to take
quite some time; more than most sane people want to wait... ;-)
TCP/IP stacks are pretty persistant, and will retry for quite some
time, usually, before giving up... But, eventually, it would, and
then your blocked read()/recv() should fail...

[mlampkin]

If you want to do a periodic polling system... instead of a potential block on read and being dependent on the default time set for your tcp stack impl... the select call (blocking, blocking & timed, non-blocking polling) should return the error... also a call to getsockopt with the SO_ERROR option set will return the socket's current status...

Then again... if you're doing a thread per socket system or something similar... waiting for read to throw and error is probably the easiest to implement...

...and yes... STILL trying to get back in the lead for posts against ROB... that @#$%#* !!!! ;-)

Michael