Is there a way to do a keep alive ping type thing from a separate thread, to prevent disconnects?

[fleet anvil]

I am developing for the Meta Quest which requires when you remove your headset you don't get disconnected, and they say "Avoid disconnection by implementing keep-alive networking on a separate thread"

[topaz rose]

Mirror already has a Ping-Pong exchange as long as the client doesn't go to sleep. if it does, it wouldn't matter what thread that was on.

[fleet anvil]

I believe they are saying the main thread is somehow paused when the app goes to the background, but other threads can stay alive

[topaz rose]

nonsense. If the app goes to background / sleep all threads would be suspended

[fleet anvil]

I have no idea. I'm just going based on their requirements here
https://developer.oculus.com/resources/vrc-quest-functional-11/

[mild laurel]

"User stays connected for at least 1 minute."

Try setting KCP timeout to cover that, then test?

[fleet anvil]

The issue with that then is when players quit the game they are left online for over a minute, as Quest doesn't fire off the Application quit event when it exits games

[topaz rose]

This would be a Unity bug you need to report if true

Quest doesn't fire off the Application quit event

[fleet anvil]

It's been ignored for years, so that won't be a solution for it, unfortunately

So I'm trying to figure out how to match the requirements of what Quest tells developers to do, ie the link I sent that says a background thread for some reason

[topaz rose]

What happens when you do this test?

[fleet anvil]

They get disconnected, as I currently have the timeout at 15 seconds so players aren't left around for a while in the servers after quitting

[topaz rose]

Are you overriding OnApplicationQuit in your custom network manager? If so, are you calling the base.OnApplicationQuit ?

[fleet anvil]

OnApplicationQuit does not get called for Quest headsets

[topaz rose]

that's really unfortunate

That makes it a Quest or Unity bug we can't overcome without extending the timeout as mentioned on the transport.

[fleet anvil]

So there's no other potential solutions? There's no way to do the background thread keep alive like their documentation says to do?

I know you said you don't think it will work as the game should pause background threads too, but is it possible? If its possible to do a background thread keep alive, then I can at least test it to verify

[topaz rose]

You can try a coroutine or InvokeRepeating that call a Command > TargetRpc from player every 5 seconds, and log it on server to see if it keeps appearing with headset removed / menu open. Since Unity is single threaded, I suspect that will also suspend, but you're welcome to try. Their "guidance" probably doesn't take into account single-threaded environments like Unity. They're more likely considering a real .Net app

[fleet anvil]

Coroutines run on the main thread, not a separate thread

Unity CAN run different threads, but their own API is limited to the main thread

So a networking system, if not reliant on Unity APIs, can run on a separate thread for a keep alive ping

[topaz rose]

exactly what I was saying

[fleet anvil]

So how do I do a keep alive from a separate thread though? Coroutines won't be it

[topaz rose]

you're in a custom mono world, not in .Net FW / .Net Core - threading is trash in unity

[fleet anvil]

So are you saying its literally impossible to do a keep alive ping in Mirror from a separate thread? That all the networking stuff is reliant on Unity's main thread API with no other option?

[topaz rose]

Mirror isn't your problem, so maybe stop blaming us for Unity's shortcomings?

[fleet anvil]

I am not blaming Mirror. This is a Quest/Unity issue. I'm just trying to find a workaround as they will not fix the OnApplicationQuit issue.

However, multithreading does work in Unity. You can run code from other threads. I know because I've done it before. What doesn't work is typically any code in the UnityEngine namespace on a separate thread

[topaz rose]

There are Tasks, but I don't know of Unity has them tied to the main thread or not

[fleet anvil]

I know how to run code from other threads. What I don't know how to do is a Mirror keep alive ping. Is it possible? Is it dependent on UnityEngine namespace code?

[topaz rose]

even with a Task, you've got to get to Mirror and send a msg on the network to have it kept alive, otherwise the server will time it out.

[fleet anvil]

So you're saying I would use Network Messages to send a message from the client to server? That's the only way to do a keep alive type ping?

Using this, right?
https://mirror-networking.gitbook.io/docs/manual/guides/communications/network-messages

[topaz rose]

yes, but you still need NetworkConnectionToServer, which inherits from NetworkConnection, which has
using UnityEngine;
in it

[fleet anvil]

That may be fine. Looking at the code, what it does is call the Transport immediately with no other Unity code in there. So if the Transport is multithreaded capable (I'm using Ignorance), then it should work

Looking at Ignorance code, it does run on a separate thread. I think this should all work multithreading. Thank you for your help

[topaz rose]

wait - all this time this was about #ignorance ? That's a DLL if I recall...you couldn't ask in there about it's internal keepAlive?

🤦

[fleet anvil]

Um sorry? It's not like I know the internal code of Mirror and that Ignorance has its own keep alive code? I figured that was a Mirror thing, and the transport is just how its sent

[topaz rose]

Early on Jesus told you to change the KCP timeout - that would've been a good time to mention you weren't using KCP.

every transport has its own keep alive mechanism

Mirror is agnostic about transports.