Timeout for recv() ?

Hi Folks,

I've written a multithreaded server application with the following problem:

On a client connect, a new thread will start.
Clients will send a pingsignal for validating server accessibility, the other way arround I want to have something like a timeout for the server.

If for example no data is received for 1 minute, the server should drop that client. Code looks like this:

Code:

---

do {
                  rec=recv(ss,buffer,BUFLEN,0);
                  if(rec>0){
                        printf("Thread %u (%s): - received bytes: %d\n", pid, remoteaddr, rec);
                }
                else if(rec==0){
                        sprintf(errormsg,"Thread %u:\Connection was closed. %s(%s)\n\n",pid,remoteaddr,data->h_name);
                          printf(errormsg);
                        error = TRUE;
                          break;
                  }
                else{
                        printf("Thread %u (%s): error while reading(recv()): %d\nConnection interrupted.\n", pid, remoteaddr, WSAGetLastError());
                }

    // cut
       
                  memset(buffer,0,BUFLEN);               
        }while(rec>0);

---

with that code, the server thread won't detect if a client hang, crashes or just reboot.

So now my question, can I setup a timeout for recv() or have I to do this on my own with some kind of timer?

Thanks in Advance,
Andy

Can't anyone read MSDN anymore??? :confused: :confused:

Direct from the page for recv(), emphasis added....

Quote:

---

If no incoming data is available at the socket, the recv function call blocks and waits for data to arrive according to the blocking rules defined for WSARecv with the MSG_PARTIAL flag not set unless the socket is nonblocking. In this case, a value of SOCKET_ERROR is returned with the error code set to WSAEWOULDBLOCK. The select or WSAEventSelect functions can be used to determine when more data arrives.

---

Use SO_RCVTIMEO in SetSockOpt()

You can also create a scavenger thread, whose only job is to check for recent activity on all sockets, and call close() on sockets with no recent activity. Any thread can call close, and the call to close from one thread will cause an immediate return from a blocking recv() in another thread.

Mike

PS to TheCPUWizard: I think he knows about the MSDN quote. He is using blocking sockets, so the first half of the quote (about recv blocking indefinitely) is his problem, whereas the second half of the quote (about recv() returning SOCKET_ERROR for non-blocking sockets) is not applicable.

The point I was trying to make [perhaps very unclearly in retrospect :blush: ] was tha WSARecv(...) might very well be more appropriate for this type of operation than the move basic recv(...).

When dealing with a server, the ability to have overlapped I/O, completion ports and the like, typically make for a more robust design in my experience. If I am targeting a Windows Platform [i.e. not concernec with portability], then my network layer is almost invariabily based on the WSA... routines because of the additional configuration options.

Quote:

---

Originally Posted by TheCPUWizard

When dealing with a server, the ability to have overlapped I/O, completion ports and the like, typically make for a more robust design in my experience. If I am targeting a Windows Platform [i.e. not concernec with portability], then my network layer is almost invariabily based on the WSA... routines because of the additional configuration options.

---

No argument there: you're 100% correct that overlapped I/O etc are all more robust and scalable than the OP's architecture, which is a one-thread-per-connection server.

Of course, most beginners to networking find Winsock more understandable with the simple one-thread-per-connection architecture. And for low-volume servers, which will never scale beyond a few 10's of simultaneous connections, there's really nothing wrong with it.

Mike

Agreed, there is nothing wrong with simple solutions. :) :)

On the other hand, I prefer to have developed one extremely well tested set of classes that I can use in all of my applications, regardless of most vartiables [such as scalability]. For my purposes, the time invested (years ago) has paid off time and time again...

HI,

You could use the select() API to wait for incoming data with a desired time out value.

bye
P.Somasundaram