Reconnect to room on a Relay Server
-
Hi Alessio,
I think we've identified your test app and lobby. We believe that both
Disband at Start
Allow join in progressare enabled for that lobby. Unfortunately - they shouldn't be - this is a regression in Portal-X - it should be disallowing that combo.
So what we believe is happening is player B is re-authenticating before attempting to re-connect.
Because Player B now has a new session, he/she also has a new connection id (i.e. cx) - and the Relay Server seems them as a new person.
Because "Allow Join in Progress" is enabled - the Relay Server attempts to contact the lobby to see if this user is valid - but that lobby doesn't exist anymore - and we get the error you are seeing... (which is maybe not the best error message).
Disabling "Allow join in progress" will result in a more understandable error message - but probably won't fix the problem.
The real trick to this scenario would be for the network re-connect to the room server to happen without recreating the CX - but depending upon the type of network failure that is probably unavoidable.
The devs are looking into options.
Paul.
-
Thanks Paul, I really appreciate it.
Bear in mind that the player could also disconnect due to a crash or the mobile device being turned off, so the possibility of re-entering the room even after having performed a new authentication would be very very important.Please let me know!
Alessio
-
Also Alessio,
Agreed with your scenario - we are prioritizing a improvement to deal with that scenario for you.
Also that maximum # of servers is a limit that we can control per-app - so we can bump that up.
Paul.
-
Hi @Paul-Winterhalder, any chance to have new developments regarding reconnection in the room?
-
Hi @Alessio-Falsetti - checking with the devs.
I believe we have a short-term Relay Server patch that makes reconnecting generally more reliable -- but also a change for 5.2 that can allow reconnecting across sessions... (that will be an option for the dev to enable).
5.2 is currently targeting mid-to-late February for release.
-
Great! Happy to hear that!
-
Ciao @Paul-Winterhalder, @Greg-Moulds,
I have updated BC to 5.2, so I can implement the rejoin in the room. But it's not clear to me how to implement it. The only information I found is in the release notes where it only says this:Reconnects - Relay Servers now better handling reconnect scenarios. There is also an option to allow reconnects even if the user’s session has changed ("ALLOW_REJOIN_BY_PROFILE_ID": "true").
How does it work?
Thanks!
-
Hey @Alessio-Falsetti . In order to enable that feature, you need to update the "Custom Environment" settings for the appropriate "My Servers" definition:
-
Hi @Greg-Moulds ,
ok, I've updated the custom environment of my server, and now? If I try to rejoin the room, I receive alway this error:
"status":403,"reason_code":90300,"status_message":"Server Closed Connection","severity":"ERROR"}.I'm using:
RelayService.Connect(RelayConnectionType.TCP, connectionOptions, null, failureCallback);What should I do?
Thanks! -
Hmm...
Let me poke around. -
So a question for you... are you able to connect initially and it's failing on the reconnect? Or are you failing to connect at all?
-
I'm assuming from your statement "if I try to rejoin the room" that you've connected successfully initially.
-
Yes, works well first time.
-
However, reconnection doesn't work.
-
Ok thanks @Alessio-Falsetti . We're still looking into it so I'll let you know when we have an update.
-
@Alessio-Falsetti Next question... what are your "Disband on start" and "Allow join in progress" settings for this lobby type?
-
Ok @Alessio-Falsetti ,
I'm 99% sure I know what's going wrong. Correct me if I'm wrong but your lobby type configuration has both "Disband on start" and "Allow join in progress" set to true.
This was a bug in our portal that existed up until the recent 5.2 release. Now, you cannot set both those values to true. The portal (neither portal-X nor the legacy portal) will not allow you to do this.
All that said, your lobby type configuration was obviously created before we fixed this so your lobby configuration is in a bad state and you need to choose one or the other.
I don't know enough about your use-case to say which you should choose but if you want to ask for some guidance, let us know and we can take a closer look at your requirements and figure it out.
For now, you can just do a quick test by turning one of "Disband on start" or "Allow join in progress" off and re-run your test.
Let us know how it turns out! -
Ciao @Greg-Moulds,
yes, you are right... I had both "Disband on start" and "Allow join in progress". I removed "Allow join in progress" and now the re-connection works normally. I'll do some more testing, but this seems to have solved the problem!
I'll let you know if I discover anything else!Thanks a lot!
-
Great @Alessio-Falsetti Glad to hear it!
-
Ciao @Greg-Moulds and @Paul-Winterhalder ,
a question about the relay server: a lot of time passes from the UpdateReady call of a lobby to the arrival of the ROOM_READY state, around 30 seconds on average. This should be the server instantiation time the first time. But if I have a "Keep idle server warm" set to 15 minutes, why if other players create other rooms, then they always have to wait 30 seconds or more? It seems like a new instance is created every time.
It's a really long time, if you consider that a match of our games lasts less than 2 minutes. Is there a way to avoid this wait, at least after the first time the server is instantiated?These are our server settngs:
