Random disconnections while simulating packet loss

I’ve been simulating small amounts of packet loss (around 2%) and the client has been getting disconnected every time. I have the Disconnect timeout set to 10 seconds, and the ping timeout set to 5 seconds.

Data is still getting to both instances just fine as both can see each others’ characters moving.

Is there anything anyone knows about how to prevent these disconnections? I’ve narrowed it down to being packet loss related, even at simulated 1% loss rates it still happens. I’ve also tried connecting to an instance of my game running from a tethered hotspot and it still disconnects.

I just tried setting the ping timeout to 10 seconds, and that pretty much immediately caused a disconnection after about 12 seconds or so after joining. Is it something to do with ping timeouts? It’s currently set to 5 seconds, as that seems to keep them connected when there isn’t any packet loss at all.

After looking for this bug in the bug tracker, both of the ones I found were flagged as “By Design”. I honestly can’t see how Unity team can expect there to be absolutely no packet loss from the real world internet.

Is there any help I can get here?

So is UNET broken in this case? Or has nobody else ever had this happen? I’d hate to think it’s broken because it’s something I want to use, but after getting no help and not finding anything else on this subject it’s the only I can say about it.

It works much better in the real world, as I understand the simulation is not that good yet. I’m no expert on uNet yet, Only made 2-3 games with it but in the real world, it works well with none webGL clients specially. The webGL issues are being resolved as well but the simulator currently is not in the best state or I just misconfigured it like you.

I’ve tried tethering a computer to a phone’s hotspot, and it still disconnected roughly the same. Even with using an external network simulator (Clumsy) it still does the same. My game isn’t the standard competitive FPS either (I’m working on a co-op campaign based game), so generally connections will probably last longer than 10 minutes or so and I’d hate to have people need to reconnect every so often, especially when it seems to happen randomly which can cause lost progress.

Isn’t there a way to notify a Unity dev or something? I’d really like something official about this issue.

There is a uNet improvement thread on top of sticky threads of multiplayer forums. Go write your feedback there.

Great thread, i have deconnection bugs on my webGL game.
This could be the explanation for my problem too.
I am in contact with the unity QA, i keep you informed.

1 Like

I mainly just wanted to see if there was a potentially easy fix before I made mention of it there, because I’m sure there’s plenty of things that could’ve escaped me that could’ve fixed this. I also just can’t for the life of me understand how they expect there to be no packet loss (I know the internet nowadays generally doesn’t lose that many packets anymore) because it’s something that you can’t control.

Any news on this, i didnt get any from the QA guys btw.

I don’t have any. After even more testing I still just come to the same conclusions that any amount of packet loss will eventually lead to a disconnection. Which is fine and all for games where you’re only connected for minutes at a time I guess, but when you are expected to be connected for hours at a time it’s a massive problem.

There is a bug related only to WebGL which I’ve submitted and it will be in a future patch release. It’s fixed. The buffer for receiving messages is not sometimes big enough and they made it configurable but it’s only for WebGL.

How small was that buffer? And is there any way to see how many buffered messages there currently are? If I’m reading your post right, you’re saying that although they let you change the buffer size it doesn’t actually do anything to non WebGL games?

It’s only related to WebGL games which use webSockets, All other platforms use UDP and uNet’s own protocol and transport layer.
The buffer was 4k in size by default. I saw the bug when the buffer could not receive the incoming data and would issue a warning in the log and cause disconnects (it seemed there is a causal corolation between them).
There are methods for getting Network stats but I don’t know if they work in WebGL too or not.

I’m seeing this too. I try simulating packet loss with either clumsy or the networkmanager simulator and I can visibly see the network slowly degrade (position updates start to come less and less frequently on my player prefabs) before I start getting “failed to send internal buffer” errors and disconnection. No WebGL here, just simple windows builds. I’m not syncing anything crazy, just position and rotation + timestamp updates 15x per second, and using only unreliable channels.

I guess someone should post this thread in the improvements thred for uNet team to see.

1 Like

Hey Ashkan you were the uLink guy! I miss uLink :frowning: Sometimes I think about still using it because I know it still works but with every unity patch I’m afraid its going to break.

Someone should some rewrite the uLink statistics GUI to work with unet so I could actually calculate my traffic easily. I still use the ConsoleGUI since it really had nothing to do with uLink.

Yeha I miss uLink as well and still use The console GUI. In uNet you should use the profiler for now and the report is more detailed than uLink there actually.
The issue is not the GUI, The statistics functions don’t work atm in uNet.

Hello guys. @Ashkan_gc thanks for pointing this thread.

@srylain : difficult to say, so far i don’t know do u use udp or tcp (web sockets), what qos channel do you use, what is your bandwidth, how many messages and what is the message size? The easiest way is - report the bug and attach bug number here + ping me. I will take a look. But I suppose that in your simulation packet loss is more than 2%. Anyway, I guess you can do 3 things right now

  1. Reduce ping timeout back to 500 ms
  2. Increase NetworkDropThreshold to 40% (in connection config)
  3. Decrease packet size to 1400 bytes (in connection config)

@PrimeDerektive : please point number 2 from the list above. Should help.

@Paradoks : hey man, Web sockets is a different story, almost no parameters in connection config works with web sockets. I guess that your “disconnects” related to library itself. I do not believe that tcp connection can be disconnected easily without any internal problem What is the your reported bug number?

Sorry, guys, my fault, a lot of work in last month cause that i read that forum quite rare… Ping me directly please if you think that you need my attention. Again unfortunately i cannot read everything :frowning: I’m sorry about this

Hi @aabramychev , i just sent you the case number in pm.

Vaidas tryied to reproduce the case and found no bug, but as i told him, i think he used a virtual machine instead of a real distant server like my EC2 so the bug could not occur because there was no packet loss or connection problems.

but i dont know if he get my latest message as i got no answers from him since april 26th.

Could you keep me informed please ?

thx.