I have a UNet server with normal sockets and websockets (websockets are handled by spawning a second server which hands over external connections to the main one). When a websocket client disconnects, this fires a disconnected event on the main server and all is well. However, if a websocket client attempts to time out (eg disconnects internet and waits for a while), the server never seems to detect his. I've tried waiting for upwards of 20 minutes and still nothing. Should websocket connections eventually timeout? How long should it take? Does it use the normal connection config timeout values? Is my setup of handing websocket connections over as external connections potentially causing this problem? I'm currently working around it by manually sending keep alive messages and checking for timeouts in the NetworkManager's update function, hardly ideal but it seems to work. Thanks Sandy
What version do u use? the deal is in the last version this problem has been already solved, as websockets support keep alive packet exchange (not tcp keep alive but custom one)
Thanks for the prompt reply! I am current using 5.6.0f3 Which is the 'last' version you refer to? I'm hesitant to upgrade as we're about to push this project out the door, but if it's a minor one then it might be worth it.
5.6.1p2 should have this fix. Config.Pingtimeout will define how often peer should send keepalive, and disconnecttimeout will define when connection will disconnected if no incoming traffic have been received during this timeout
That's good news, I hadn't seen it mentioned in the release notes. Thanks - I will update and give it a go.
I've tried it now and the timeout does seem to work well. Thanks! However, while my WebGL game sat there offline, threw an exception - see attached image.
So this crash bug here was actually something that came back due to the upgrade, where it overwrote a change in the WebGL playback engine in order to sidestep this bug: https://issuetracker.unity3d.com/is...hrown-when-clicking-lan-client-on-webgl-build Disappointing that that issue still hasn't been fixed, but at least the websocket timeouts seem to be fine now.
@sandy-macpherson, ups, looks like a bug I will take a look. Sorry about this, cannot foresee all use cases by myself
Thanks @aabramychev ! I've had the fix in place from that link for several months now and can report it appears to work fine. Clearly the array can legitimately hold NULL values and this just checks for it.