OK.. from reading around it seem like that the only way for me to set a timeout on the recv function call is to do it with the setsockopt function, so here is what I did.


But it doesn't seem so work, because its staying in the recv call untill a message arrived so when a reset is detected on the device that its telneting too.

Is there another way I can make it time out?

Did you try setting tv.tv_usec to 0 (instead of letting the uninitalized value create undefined behavior)? It works for me.

On my system, just for kicks, I printed out the (uninitialized) value for tv_usec. It showed 3213791376 , which (in microseconds) is a little less than an hour, so it might have timed out if I had waited long enough. Of course the behavior is undefined, so in other cases it might have waited no more than the number of seconds you told it, or it could have used just about anything for tv_usec . The maximum number of microseconds for a 32-bit integer would be something over an hour.

Regards,

Dave

Footnote: You can also use select() with the timeval struct values to effect a timeout on a socket (different timeout value is possible for different calls).

See Beej's Guide to Network Programming: http://beej.us/guide/bgnet/

Yup tried that and its still the same.

I don't get why when I reset the device it comes out of the recv call with zero BUT if I turn off the device, it never comes out of the call.

Is this where I should be setting the SO_LINGER option? or maybe the SO_KEEPALIVE?

I have no idea. Sorry. (Maybe someone else has had experiences with these.)

On systems that I have used and for programs that I have tested, If the server device is turned off or reset, recv() returns with a value of zero, whether it's set up for timeout or not (since the socket connection is broken).

[edit]Well, I shouldn't have said what happens when it is turned off, since I have nothing with which to test, just now. How are you testing?[/edit]

What kind of system is the server running on?

What kind of system is the client running on?

Can you post the code for your client?

Regards,

Dave

Oh sorry I can't post the codes.

im testing one of this data controller http://www.viasat.com/datacontrollers/

I use socket to telnet to it and are able to send command and recv feedback from it, im just having problem figuring out how to detect if the device is shutdown because the recv function is not returning... it only return when it detect a reset for some reason.

thanks for your help... I'll try something else.

So: Your client is running on your PC, right? Here's what I did to test the recv() after using the setsockopt that you showed:

1. I compiled the server.c program from beej's guide (Source code downloaded from http://beej.us/guide/bgnet/examples/) I tested it on my PC by using the client.c example from beej.

This server program is designed to monitor a certain port and send "Hello, world!" to a client every time a connection is made. It runs forever.

I compiled and executed the client on my PC (Linux, Centos 5/gcc 4.1.2). The client is designed to request a connection, then look for the message from the server and quit. (No timeout.)



2. I cross-compiled the server program for an embedded Linux system that I just happened to have "lying around," and downloaded the server to make sure it works as advertised. I exercised it with the client program running on my PC.

3. I modified the server so that delayed five seconds (with sleep(5)) after granting the connection to the client before sending the message to the client. I won't post the server code, since it is on beej, but here is the part that I modified:


4. I modified the client so that it would use your setsockopt() call to set the timeout for three seconds. Then I put in a loop that would go continuously until the receiver actually received the message.

Here is the part of client.c that I modified:


Results of testing:

When everything was "normal", the client loop reported one timeout, then got the message. The output from the client looked like this:

Then I started the client again, and before the 5-second timeout, at the server, I soft-booted the embedded system running the server (with the Linux reboot command), the embedded system shut down ports, etc., and the recv() on in the client program returned with zero, so that it terminated.

I repeated it, but this time when I powered down the embedded system (or when I hit the hardware "reset" button), the client stayed in its loop, timing out every three seconds).


In other words, the timeout set up by setsockopt() works exactly as I expect on my system.

What's the point? Well, instead of testing one particular problematic "feature" inside a big complicated program, test it by itself with on a program with minimal functionality. In this case, just testing client and server both in the PC was enough to convince me that the setsockopt timeout thingie looked as if it was working.
Now, i (obviously) couldn't test the thing about rebooting or powering down the server when client and server were both on the same system. I could have used two PCs, but I wanted to try it on an embedded system, just for kicks.

Regards,

Dave

These are some very good examples, thanks a bunch dave... it could be problem with the tcp stack or whatever on the embedded integrity system we are running on.

Thanks for all your help.