Disconnection when quitting and changing the app

[FOKSlab]

Hi, I tried Reality Mixer on my iPad Pro and it works on some apps but when I quit an app and launch another one network connection is broken. Is this forecasted to do something about this ? Is this an issue on the Reality Mixer side or on the app side (the app may stay connected in the background) ?
It would be great to make available the auto disconnection/reconnection behaviour (deleting the current connection if no data is received and trying to reconnect next)

[fabio914]

You'll have to go to the Reality Mixer app and disconnect before launching the next game, you can then connect again once the other game has finished loading.

[FOKSlab]

Hi, Thanks for your answer. I already found this process but I was wondering if is there a way to auto-connect Reality Mixer app when detecting a compatible MRC app on Quest and disconnect when app is not running any more ? It would be a great feature to add in your software if possible so iPad can be used to get a "Chromecast-MRC-like" feedback of what the user is doing in the headset. Regards, Marc LR

…

________________________________ De : Fabio ***@***.***> Envoyé : vendredi 12 mars 2021 04:11:19 À : fabio914/RealityMixer Cc : Marc Le Renard; Author Objet : Re: [fabio914/RealityMixer] Disconnection when quitting and changing the app (#55) You'll have to go to the Reality Mixer app and disconnect before launching the next game, you can then connect again once the other game has finished loading. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHUU3EA65IHO7IFWSKCD62LTDGA5PANCNFSM4Y36WILQ>.

[jonathanperret]

Hi, Thanks for your answer. I already found this process but I was wondering if is there a way to auto-connect Reality Mixer app when detecting a compatible MRC app on Quest and disconnect when app is not running any more ? It would be a great feature to add in your software if possible so iPad can be used to get a "Chromecast-MRC-like" feedback of what the user is doing in the headset.

That would be nice indeed. But an issue is that because the MRC server process is actually part of each Quest app, when the Quest app exits, if there is an established connection it is closed from the server (Quest) side, causing the Quest-side socket to enter the TIME_WAIT state (see http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html for a good explanation of the issue).

That TIME_WAIT socket unfortunately prevents the next started Quest app from starting its own MRC server on the same port. This is why you occasionally end up with a Quest app that supports MRC but that you can't connect to using RealityMixer (or any other MRC client): the app couldn't initialize its MRC listener because the port was busy with a "dead" socket. This can be cleared up by restarting the Quest (hence the "When in doubt, reboot" advice on https://developer.oculus.com/learn/mixed-reality-technical-and-trailer-video/), but waiting a few minutes for the TIME_WAIT socket to go away and restarting the Quest app would work just as well (if you have developer mode enabled on the Quest you can check if a lingering socket exists by running adb shell "netstat -ant|grep 28734").

There are ways to work around this TIME_WAIT issue but unfortunately all of them would require a modification on the Quest side, and even worse, the listening socket is created by a library that is part of the Quest OS so even the cooperation of Quest app devs would not be sufficient.

So as far as I can see, we're stuck with having to manually disconnect RealityMixer before quitting a Quest app (remember that the TIME_WAIT state does not occur if the client initiates the disconnection), if we want to be able to reconnect to the next Quest app without waiting or rebooting. Hence I think modifying RealityMixer to auto-reconnect would not be very convenient — in practice you'd have to reboot the Quest everytime you change apps.

I'd love to be proven wrong though — or for Oculus to change the MRC lib in the OS to use SO_REUSEADDR so it (hopefully) wouldn't be vulnerable to that TIME_WAIT issue!

[FOKSlab]

Hi, What a pity Oculus did not forecast to"switch" between 2 MRC-compatible app ! I could see a solution maybe (I am full of ideas but impossible to implement sometimes ;) !) : maybe you could monitor Quest to get current running task (doing this from a computer with adb is easy but from iOS I do not know if it is possible) and control the Quest from Reality Mixer. This way you could ask from Reality Mixer for app to launch/run wait a little and then ask for MRC connection, and when you want the user to change the app, you can tap on the iPad/iPhone to disconnect / quit the current app / launch the next app / wait a little and reconnect ? This is only possible if you know which app is MRC compatible (and maintain the list on iOS side). It is always easier to say than to do but I would like to share this with you. It may give you some ideas for future releases ;). Regards, Marc LR

…

________________________________ De : Jonathan Perret ***@***.***> Envoyé : vendredi 12 mars 2021 14:17:33 À : fabio914/RealityMixer Cc : Marc Le Renard; Author Objet : Re: [fabio914/RealityMixer] Disconnection when quitting and changing the app (#55) Hi, Thanks for your answer. I already found this process but I was wondering if is there a way to auto-connect Reality Mixer app when detecting a compatible MRC app on Quest and disconnect when app is not running any more ? It would be a great feature to add in your software if possible so iPad can be used to get a "Chromecast-MRC-like" feedback of what the user is doing in the headset. That would be nice indeed. But an issue is that because the MRC server process is actually part of each Quest app, when the Quest app exits, if there is an established connection it is closed from the server (Quest) side, causing the Quest-side socket to enter the TIME_WAIT state (see http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html for a good explanation of the issue). That TIME_WAIT socket unfortunately prevents the next started Quest app from starting its own MRC server on the same port. This is why you occasionally end up with a Quest app that supports MRC but that you can't connect to using RealityMixer (or any other MRC client): the app couldn't initialize its MRC listener because the port was busy with a "dead" socket. This can be cleared up by restarting the Quest (hence the "When in doubt, reboot" advice on https://developer.oculus.com/learn/mixed-reality-technical-and-trailer-video/), but waiting a few minutes for the TIME_WAIT socket to go away and restarting the Quest app would work just as well (if you have developer mode enabled on the Quest you can check if a lingering socket exists by running adb shell "netstat -ant|grep 28734"). There are ways to work around this TIME_WAIT issue but unfortunately all of them would require a modification on the Quest side, and even worse, the listening socket is created by a library that is part of the Quest OS so even the cooperation of Quest app devs would not be sufficient. So as far as I can see, we're stuck with having to manually disconnect RealityMixer before quitting a Quest app (remember that the TIME_WAIT state does not occur if the client initiates the disconnection), if we want to be able to reconnect to the next Quest app without waiting or rebooting. Hence I think modifying RealityMixer to auto-reconnect would not be very convenient — in practice you'd have to reboot the Quest everytime you change apps. I'd love to be proven wrong though — or for Oculus to change the MRC lib in the OS to use SO_REUSEADDR so it (hopefully) wouldn't be vulnerable to that TIME_WAIT issue! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHUU3EAUJWBBDJOOK3YBB4TTDIH6ZANCNFSM4Y36WILQ>.