Session retained by one of its privates?

[mikeCalvir]

At the end of the communication sequence, once both sides know it is over they simply release the ROUSession, and leaving pending messages that can't ever be sent.

However, the session isn't ever released it seems, it keeps on trying to send the messages.

I was hoping you might recommend an approach here, and/or review the code or add a "stop" method or similar :)

[mgoemmel]

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;
  }

[mikeCalvir]

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 notifications@github.com 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.

[mikeCalvir]

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.

[mgoemmel]

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.

[mikeCalvir]

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?

[mgoemmel]

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 :)

[mikeCalvir]

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 :)

[rabovik]

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.

[mikeCalvir]

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.