UNET - WebGL (WebSocket) clients get disconnected from server

We've got a WebGL build of our realtime multiplayer game using UNET networking. For WebGL clients, we've got NetworkServer.useWebSockets = true; and then, we're using a ServerSimpleWrapper for our standard UDP (iOS, Android, Mac, Windows) clients. Regular UDP clients do not get disconnected from the server, but WebSocket clients do. We've tried setting the LogFilter to everything from LogFilter.currentLogLevel = (int)LogFilter.FilterLevel.Warn; to LogFilter.currentLogLevel = (int)LogFilter.FilterLevel.Developer; but we don't get any useful information back in either the server or the client log. We're registering NetworkServer.RegisterHandler(MsgType.Disconnect, uNet_OnPlayerDisconnected); and that handler is called, but that's it. No errors, no warnings, etc.

How can we track and fix this issue?

 

You have to set useWebSockets = true on the server. And possibly on the client too, but the server is the important part. At least that's what I figured from my testing.

 

Thanks for the response, but I already stated I have NetworkServer.useWebSockets = true;
Also, it's not that the client can't connect at all. It does connect and plays through some of the game, but gets disconnected in the middle of the game. It seems (though I've had trouble locking this down to being definitive) that the more data transmitted, the more often the disconnects.

 

To clearify what exactly is happening, I'm working on the project with Ben (DimensionU), We get connected and play but when we connect many clients and play, mid game some connections get lost but we don't get any specific warning in logs regarding not being able to send data or receive it neither in server nor client.

 

I submitted a bug report. Case 776396.

 

Any news on that guys ?
I am too making a WebGL game hosted on a EC2 server.
I can connect but when i spawn creeps seems like there is a overload or something and it crashes the server.
Strange thing is: it doesnt happen when i make it not webGL, i mean when :
Server = EC2 - Client = standalone.

 

We unfortunately never received any answer from Unity Technologies at all.
What I can tell you to hopefully help you a bit.
CPU usage is important and if your program eats a lot of CPU time in other places, the networking subsystem will not have the chance to dispatch messages and you'll get disconnects.
Since the connection is fully TCP based and no unreliable channel exists, all messages have to be cueued and sent so be careful on what you send and how much you send. Make sure to use delta state syncs, throttle message sends and ... Also play with ConnectionConfig paramters like timeout and sendCueueSize which might help.

Please let us know how things go and what you find out

Just my 2 cents

 

I just sent a bug report for my bug, i keep you informed.
btw, i am not sure that my problem, if it is the same as yours, is related to cpu overload as
my game runs well when i host on linux headless and when i connect clients with standalone and editor.
i think that the problem is more around the webSocket as when i check useWebSocket i cant connect anymore with
editor and standalone, and i got problems with my webGL client, wich should not happen as it should be the same thing than editor - standalone.

 

Our game runs well too in terms of FPS, it achieves 30 frames per second. The thing is first of all I only talked webGL client perf so performance of the headless server and standalone clients/editors don't matter at all.
If you disable some CPU heavy operations in your game you can see network perf improves. Performance of UDP connections is not comparable to TCP ones .The bad thing is that there is no log messages helping us.

The Websockets implementation of uNet is not as good as the UDP one and not as mature as that at all.

Now that WebAssembly is out partially hopefully unity can get more serious about the webGL thing and let's hope WebRTC which uses UDP becomes more prominent.

 

I bump, as i would really like to get the unity devs opinion.

 

Hi @Paradoks - I don't think we're having the same issue. our game server doesn't crash. Instead, our WebGL clients just get disconnected, without any exceptions being thrown or errors being logged by the server. I have done quite a bit of testing and here's the most information I can get...

I had 2 clients get disconnected at the same time. One was Chrome and one was Firefox.

Console Log from Chrome: WebSocket connection to 'ws://xxx.xxx.xxx.xxx:28000/' failed: Invalid frame header
Console Log from Firefox: The connection to ws://xxx.xxx.xxx.xxx:28000/ was interrupted while the page was loading.

Any chance this sheds any light on what's happening?

The web page hosting the WebGL game client is being served on IIS, but I've also hosted it on apache and had the same problem.

 

Hi @DimensionU

- You say that you have clients that get disconnected, but did you configure your networkManager to reload the same game scene ?
- If you reconnect to the game do you disconnect again ?
- do you spawn something heavily ?
- is the server linux headless ?
- where do you see the server logs ?

- me, for my problem, i realised that the diconnection is coming after i launch the first spawn wave, that is exactly 30 npc running in the map, they are spawned, and 3-4 second later it disconnects.
- it happens only on my linux headless hosted on a EC2 amazon server, if i host with the editor or a standalone using webSocket, i dont get any bugs.
- finally i dont think anymore that it crashes the server, because i succed to reconnect time to time, it is kind of random.
- do you switch plateform when you make builds ? i realized that switching was making non identical assets for server and player wich was causing bugs too:
http://forum.unity3d.com/threads/un...ts0-assets-ress-for-read.393702/#post-2577458

i hope it helps...i keep you informed.

 

@DimensionU
Any improvements ?

 

hi @Paradoks

No news yet. Now working on deploying to a Windows ec2 instance to see if that corrects things (based on your suggestion that Linux headless could be contributing to the problem). I'll let you know when I have more data.

 

I think i made a mistake.
I am running a virtualbox with ubuntu on my win7.
I make a linux (not headless) version of the game ( the server) that i run on the ubuntu virtual box.
I connect from my host-win7-webGL to my guest ubuntu-linux
it dont seems to crash anymore...
but i did i little modification. in fact i have a kind of intuition, dont know if it is a good one.
As i said before, the game( not the server anymore finally) crashed after i launched the first creep wave of 30 units.
I thought it was like the client could not handle the massive amount of data sent to him at this time.
maybe there was reliable datas that made the game crash.. dont know yet.
I changed the script i use for sending important thing like that:
[NetworkSettings(channel=1,sendInterval=0.1f)]
so it is not reliable anymore.
I am testing keep you informed.

 

my game dont crash when i host it on a linux VM but crashes on EC2...
Any news on your side @DimensionU ?

 

I have the same problem with amazon aws microinstance

useWebSockets = false


useWebSockets = true


simple code chatserver
https://www.dropbox.com/s/qsneosvrkysr371/WebGLChat.zip?dl=0

 

I dont have any news from the unity QA, but it seems like there is a bugfix going on on the next patch, i hope it is patch that fix our specific problem.... wait and see.

 

Send a bug to unity with your project and mention in description to give it to alexeya (as he described in another post).

 

I seem to be having the exact same problem. Linux Headless server with websockets enabled, clients join for a second and then get disconnected. I noticed a few other things though.

- While the normal (non-websocket) version has about 5-10% cpu utilization while idle, the websocket version is always pinned at 100%

- On each disconnection, an error messages gets prepended to log (overwriting older log statements somehow, but that's a whole other issue):
[###] ERR: ****** 90021170 Sending new, pending truncated ...


This occurs on both 5.3.4 and the newest beta, 5.4b21

@DimensionU could you link the bug report so I can see its status?

 

The bug that we had was that receive buffer of the server was too small to receive all packets from the clients due to our packet being big and failure of receiving some prev packets. The patch for today will fix that issue and in ConnectionConfig you can configure the receive buffer size for WebSockets which the default value is 4k.

 

I'm having the same problem. Websockets clients get disconnect at random when load increases. UDP works fine. Did anyone find a working solution?

 

You probably need to increase the size of the buffer for websocket connections in your COnnectionConfig object. your connection will get a lot of messages and all of them are reliable ordered ones so you can end up with a big buffer or at least bigger than the 4k which initially is set.
You can afford to make the buffer a bit bigger but don't make it like 1MB or so just because you have memory. opens the door to DDOS attacks. Make it like 16kb or more (as much as it is needed and not more)

hope this helps

 

Just gave this a shot, let's wait and see what happens as player count increases. I'll report back! Thanks.

 

Looks like it worked! Lifesaver. Thanks a lot. Too bad this is not documented well anywhere.

 

Well Alexey from unity has a unite 2016 unite talk about networking which describes these. I was getting disconnected and found the bug in the websocket library unity uses in the logs and showed it too him so he added this buffer back then in early 2016.
unfortunately after 2017.x unity networking docs is removed in the reference, otherwise those versions have some good descriptions but you should look at docs of 2017.x in online docs when you look at networking classes. It's odd that unity deprecated this before having anything released as new version but they did that however thankfully it is there just not in newer docs