Reading some examples on net and copying some codes I was able to build a (frankstein) server that accept connection from one client and receive and send messages to it. The big problem that shows up is that I don't know when client disconnects from my server.

I've been looking for a solution, but no success. I'd read about SO_KEEPALIVE option (which could solve my problem), but I don't know how to use it (how to check the value of it).

I can't use ping because the server (machine) could be running, but not the client (software).

Anyone knows a good tutorial or how to (for beginners like me xD) of TcpIp sockets using c/c++ and how to detect when a client disconnect?

Repeat until the giant glowing lightbulb appears over your head and an angelic chorus of deceased network engineers descends from the heavens repeating the seven OSI layers in Gregorian chant. Then you'll know you've Gotten It.

A: ...
The approach taken by most application protocols currently in use on the Internet (e.g. FTP, SMTP etc.) is to implement read timeouts on the server end; the server simply gives up on the client if no requests are received in a given time period (often of the order of 15 minutes).

Protocols where the connection is maintained even if idle for long periods have two choices:

1. use SO_KEEPALIVE
2. use a higher-level keepalive mechanism (such as sending a null request to the server every so often).

'Hope that helps .. PSM

Lobinho

08-06-2010 06:23 PM

Thanks for your reply paulsm4!

I read the links (and a lot of other links), but no practical solution yet. My project is like a data logger, so I just need that my client connect, receive some data from me, disconnect, connect again, receive data... and repeat this procedure when the client need to get some information (that means any time of day).

I'll try to do some tests here... but I'm losing my hope of find a simple solution :/

Thanks anyway. :D

paulsm4

08-06-2010 06:52 PM

Hi -

It sounds like everything you're trying to do, sockets already does for you! Specifically:

1. You start your server.
He sets himself up, and starts listening for client requests.

2. You start your client. He wants to exchange information with the server.

3. The client "connects".
At that point, a NEW socket is created on the server, specifically for THAT connection.
Your server can do whatever he wants with that connection to service it - including start a new thread, or fork off a new process.

4. At some point, the server goes back and resumes listening for new connection requests. If he forked a new process, he can do it immediately (both the "server" process and the "service handler" process can run at the same time). Otherwise, you can't read any new connections until you're done servicing the current one (which is often perfectly acceptable).

5. Either way, at some point: the client is done, and he closes his socket. The server is done, and he closes his socket. The connection closes, and everybody's happy.

Thanks again for your help. The problem is that I don't know when the client finished his job, moreover, the server will send some status to the client like a 'hey client, someone pushed my button here!' (obviously, when the client is connected) in a kind of 'online communication'. Unfortunately, I can't use poll :/.

Thanks again for your help. The problem is that I don't know when the client finished his job, moreover, the server will send some status to the client like a 'hey client, someone pushed my button here!' (obviously, when the client is connected) in a kind of 'online communication'. Unfortunately, I can't use poll :/.

When the client performs some activity (ie writes or disconnects), the server can be setup to be notified of such. Look into using select(). When select() indicates that there is activity on the client socket, you should attempt to read from the socket. If recv() returns a status of zero (bytes), then that is the clue that the client disconnected.

P.S. The usage of select() is not paramount; the main thing is to examine the return value from recv() to determine if the client sent data or has disconnected. In the example above, select() will block until there is activity on the socket. If this is not desirable, then a timeout period (struct timeval) should be provided at the 5th arg to select(). Otherwise, calling recv() directly on a blocking socket will result in the app being blocked until the client performs some action.

Lobinho

08-10-2010 03:28 PM

Thanks dwhitney67,

My current code is similar to your suggestion.
I didn't know the timeout parameter, it will be very useful.