Jump to content

  • Log In with Google      Sign In   
  • Create Account


Detecting and disconnecting peers that time out?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 fjholmstrom   Members   -  Reputation: 172

Like
0Likes
Like

Posted 08 January 2013 - 12:27 PM

I've implemented a networking library with uses the techniques described in the "Tribes Networking" paper, now in my current design I have a packet window size of 32 (aka. I can have 32 packets "in transit" at any point in time, if I have not heard about the 32:nd oldest packet, I can't send any new packets out).

 

I also have a time-out that says "if I have not heard anything from this peer in X seconds we should send something", so I send a special "Poke" package from the peer that hasn't heard anything for a while and if the "Poke" does reach the other end it will respond with a "What" package (It's called a "Poke... What?" sequence in code).

 

But my instinct tells me this would not be needed, if there comes a case where I actually end up with the entire window full the peer is most likely gone already? I'm not sure the way I deal with it using Poke/What is ideal either... I suppose in theory (at least assuming non-mobile) stuff you could just disconnect them once the entire packet window fills up with un-acked packages.

 

So basically my question is: How do you usually deal with detecting timed-out peers or peers that are gone? 



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 4903

Like
0Likes
Like

Posted 08 January 2013 - 12:40 PM

The "poke/what" packet sounds like a "heartbeat," which is sometimes used to keep idle connections alive. NAT gateways may be aggressive in tearing down connections if no traffic has been seen for a few seconds, so keeping the interval < 5 seconds is a good idea.

If you send packets on regular intervals, the heartbeat is not needed. And if you exceed your window size, and time out for a number of seconds, you can probably safely assume that the remote end isn't going to be having a good time playing the game, and treating it as dropped (which it probably is.)

 

What I do these days is keep a certain amount of "slack" (this may be buffer space, or window space, or whatever,) and as soon as that slack is exhausted (out of buffering, out of window space) I declare the other end unable to keep up, and drop the connection. This works for both TCP (buffering) and UDP (window space.)


enum Bool { True, False, FileNotFound };

#3 fjholmstrom   Members   -  Reputation: 172

Like
0Likes
Like

Posted 08 January 2013 - 12:46 PM

The "poke/what" packet sounds like a "heartbeat," which is sometimes used to keep idle connections alive. NAT gateways may be aggressive in tearing down connections if no traffic has been seen for a few seconds, so keeping the interval < 5 seconds is a good idea.

If you send packets on regular intervals, the heartbeat is not needed. And if you exceed your window size, and time out for a number of seconds, you can probably safely assume that the remote end isn't going to be having a good time playing the game, and treating it as dropped (which it probably is.)

 

What I do these days is keep a certain amount of "slack" (this may be buffer space, or window space, or whatever,) and as soon as that slack is exhausted (out of buffering, out of window space) I declare the other end unable to keep up, and drop the connection. This works for both TCP (buffering) and UDP (window space.)

 

Yes, I suppose the Poke/What thing is sort of like a heartbeat. But my library is built like the Tribes Networking paper described and uses a fixed (configurable per client) rate. So a heartbeat is completely unnecessary, as you say. And if one of the connections drop WINDOW_SIZE (defaults to 32 for me) packets *in a row* - their experience will most likely be horrible anyway.

 

While the way you do is kind of "aggressive" (lack of a better word), it  seems like a really clean approach - BTW when you say "slack", what exactly do you mean? Like I've said my window size is 32 packets, would "slack" be more packets on-top of that or?



#4 hplus0603   Moderators   -  Reputation: 4903

Like
0Likes
Like

Posted 09 January 2013 - 10:15 AM

BTW when you say "slack", what exactly do you mean? Like I've said my window size is 32 packets, would "slack" be more packets on-top of that or?

I'd say that if you lose 5 packets in a row, you're probably having a bad time, so 32 packets contain a lot of "slack" already!

What constitutes "slack" is actually a game design question. Users are often willing to tolerate worse conditions than you'd like them to, so make sure to give a generous allowance for user pain. 32 packets seems like a fair bit of slack, so you're probably good! (Unless you send 60 packets a second -- 500 ms of slack probably isn't enough.)
enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS