Session retained by one of its privates? about routp HOT 9 CLOSED

I'm using a reinit method, which I call whenever I need a restart, after a disconnect and before releasing the object. Maybe this helps.

• (void) reinit {
  id old_delegate= nil;

  // send any calls from outside to nil
  if (_delegate) {
  old_delegate= _delegate;
  _delegate= nil;
  }

  _sndNextTSN = 1;
  _rcvNextTSN = 1;
  [_rcvDataChunks removeAllObjects];
  [_rcvDataChunkIndexSet removeAllIndexes];
  [_sndDataChunks removeAllObjects];
  [_sndDataChunkIndexSet removeAllIndexes];

  _rcvAckTimerInterval = ROU_RCV_ACK_TIMER_INTERVAL;
  _rcvAckTimerDelayOnMissed = ROU_RCV_ACK_TIMER_DELAY_ON_MISSED;
  _sndResendTimeout = ROU_SND_RESEND_TIMEOUT;

  self.rcvMissedPacketsFoundAfterLastPacket= NO;
  self.rcvAckTimer= nil;

  // allow calls from outside again
  if (old_delegate)
  _delegate= old_delegate;
  }

from routp.

That looks perfect, I'll try that!
You might want to add it to the repo and describe it in the Readme actually, I think anyone using this will need it.
Thanks for publishing this all btw, very useful for me as soon as I proved that the Game Center connection was losing messages (!).

On 25 Aug 2014, at 17:24, mgoemmel [email protected] wrote:

I'm using a reinit method, which I call whenever I need a restart, after a disconnect and before releasing the object. Maybe this helps.

(void) reinit {
id old_delegate= nil;

// send any calls from outside to nil
if (_delegate) {
old_delegate= _delegate;
_delegate= nil;
}

_sndNextTSN = 1;
_rcvNextTSN = 1;
[_rcvDataChunks removeAllObjects];
[_rcvDataChunkIndexSet removeAllIndexes];
[_sndDataChunks removeAllObjects];
[_sndDataChunkIndexSet removeAllIndexes];

_rcvAckTimerInterval = ROU_RCV_ACK_TIMER_INTERVAL;
_rcvAckTimerDelayOnMissed = ROU_RCV_ACK_TIMER_DELAY_ON_MISSED;
_sndResendTimeout = ROU_SND_RESEND_TIMEOUT;

self.rcvMissedPacketsFoundAfterLastPacket= NO;
self.rcvAckTimer= nil;

// allow calls from outside again
if (old_delegate)
_delegate= old_delegate;
}

—
Reply to this email directly or view it on GitHub.

from routp.

I've now seen some messages arrive in the wrong order (I was using Unreliable sending with Game Center), I suppose that is expected over UDP and I should switch to Reliable.

The problem with Reliable is that I have found that the connection can end up just hanging on a send on one side, strangely it can still receive, but one message jams all the sending, effectively jamming the game.

from routp.

When Game Center calls the disconnect callback, I'm calling the above reinit method. If both sides are doing this, it works (at least for me). My app is running in the wild for a year now and game center networking seems to works for all of my customers.

from routp.

Yep, that's working fine.

What I meant was that the messages can arrive out of order, which I found surprising because I thought your implementation would have ensured ordered message arrival?

from routp.

Order of the messages works fine for me. Strange!

By the way, I'm not the developer of the RoUTP classes, I'm only a user of it, just like you :)

from routp.

I think it's only when I run over Unreliable set at Game Center, but even so I assumed this would ensure correct order.

Thanks for telling me you are a user because I had assumed you were the developer, lol, the name should have given it away :)

Thanks for your help too then :)

from routp.

Thanks for the report.

There was indeed a bug with session retained by internal timer. I fixed it in f1721cf.

By the way, a correct way of ending the session is

self.rouSession.delegate = nil;
self.rouSession = nil;

I.e. you should set it's delegate to nil (in case there are asynchronously scheduled internal delegate calls) and do not use the same session after reconnect. (sorry, @mgoemmel, I didn't make it clear in #2)

And yes, of course messages should arrive in order, it is the main goal of RoUTP. All my apps work stable over the GKMatchSendDataUnreliable. Please report, if the issue continues to appear.

from routp.

Thanks rabovik, yes I was clearing delegate and then the session exactly as you have it but the bug meant there was still a duplicate hanging around, nice that you've resolved (sorry I probably should have helped out a bit there!).

For the message ordering, I've switched back to Reliable for the moment but if I get a chance I will see if I can reproduce the out-of-order receiving. Hopefully it is a bug in my game somewhere in that case and it would be great to resolve it.

from routp.