• Advertisement
Sign in to follow this  

How to detect abnormal user disconnection almost immediately

This topic is 2094 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,all

The main thread loops endlessly to draw a map and several rectangular images representing connected clients.The Secondary thread creates a typical win32 window(invisible,of course) and uses WSAAsyncSelect to handle network events.

when user connects and is logged in, the corresponding image on the map of the server side turns colorful,
when the client app shuts down , proper FD_CLOSE msg is notified So the image turns grayed.

SO this is my concern: When an abnormal disconnection occurred (such as cable is unplugged, unexpected black-out, OS crashes),NO FD_CLOSE message could be generated, how could the server determine the specific client dies? I know there is stuff called heart beat but got no idea how to implement it .I need elaborations.

I got another bug: In my client code ,after setting up connection using API connect(socket, ....)
I send the self-defined buffer to complete password verification. So the server is vulnerable to attacks.
That's ,someone could just connect without logging . The server would relentlessly create sockets by accetp(...) until resources are drained. So any remedy? Edited by legionalways

Share this post


Link to post
Share on other sites
Advertisement
Technically server can't know that a client has died until an expected message from client doesn't arrive. If that message is sent with set frequency then it is called heartbeat.

Let's say Client sends a message to Server each second. Suddenly Server notices that messages from Client haven't arrived for longer than second. Server now has reason to suspect that Client has died. Still, Server can only guess that it's dead. Sometimes packets get lost, so listening to single missed heartbeat is not a good idea, but still a warning sign. More than 5 missed heartbeats and the Client is likely dead.

About your second question. Since you are using win32 then you could use WSAAccept that has callback function. It is called before accepting a connection with connection data and you can return CF_REJECT to indicate that you don't want that connection. Edited by mrjones

Share this post


Link to post
Share on other sites
In my own web-server I have a time of 1 second for the first byte to receive and 5 seconds to complete the HTTP-Request.
If these are not met the connection gets closed.

This way someone must send about 60000 connects within 5 seconds. This is hard to achieve.

Share this post


Link to post
Share on other sites
Simple answer? You can't.

Longer answer: There are lots of different techniques you can use to help you to recognize connection issues with clients, a routine ping/pong for instance. Additionally, you can determine if the client is connecting too slow, or if the connection is taking too long to deliver data and make decisions on what to do. Examples include timeouts for connections that have not sent any data (standard DDOS style attack), timeouts for how long you will wait when receiving data from a client that has previously sent data (SlowDDOS attacks).

Furthermore, you should validate that all the parameters of your incoming data are within expected ranges. I can't count the number of times I've seen basic network code which went something like "read length" "allocate buffer of length" "fill buffer till length met." This kind of code is open to trivial out of memory exploits, or worse. If you know the length of your maximum packet is 512 bytes, make sure that the header's length fits that. If you know that packet type X is only Y bytes long, check that. If your world coordinates are in the range of [-10000, 10000], check that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement