Increase limit beyond 4096 connected peers

[TCROC]

What is the current reason for limiting to 4096 connected peers? And what modifications would be needed in order to increase past this limit?

We've been running some optimizations to Blocky Ball so that we are ready for the game to scale when we launch mobile. We've set up session based matches so one running game server executable handles multiple matches between different players. We are looking to be approaching this 4096 connected peer limitation.

Thanks again for all of the hard work on Ignorance! :)

[SoftwareGuy]

While I’m not sure on increasing the 4096 connection limit myself, it might be worth taking a look at the C source code for the ENet side of things. It could be hardcoded for a particular reason (explicit protocol header size?) that I’m not familiar with.

[SoftwareGuy]

Hmm, looks like the maximum connection limit is set to 0xFFF which is 4096. I’ll try to make a stress test this week that ups that hardcoded say 8192 and see it that breaks shit

[TCROC]

Awesome! I look forward to seeing the results! Also, how do you perform your stress tests? Currently I'm just spawning players on the server and controlling them on the server as if clients were connected without actually connecting any clients.

I'd like to run a stress test with actually data being sent and received across the network (even if just localhost). Spawning 1000+ Unity processes to act as clients would be too much overhead. Is there a lightweight way to simulate the server receiving cmds and sending rpcs as if real clients were connected?

[SoftwareGuy]

I honestly don't use Unity for the stress testing. I usually whip up a simple C# app that is just a single ENet-CSharp client, that will connect to the server, then remain connected until it times out or server dies. The results are two fold:

1. Does just increasing the 0xFFF value even work or is there something else hardcoded?
2. If dot point 1 is successful, can data be sent and received without anything crashing?

I'll probably tell the simple C# application to just spawn a shitload of threads per executable and use a very stripped down of the Ignorance Client of mine. Might send a periodic data packet (just a string).

As long as data flow is achieved between the server and the client, there should be no problems upstream with Mirror.

[TCROC]

Sounds good! Hopefully it's as simple as increasing the 0xFFF value 🤞

[TCROC]

Hey @SoftwareGuy ! Just checking in to see if you learned anything regarding the 0xFFF limitation?

[SoftwareGuy]

Hey @TCROC, sorry for the late reply - been dealing with some shit IRL and mood hasn't been the best.
I'll recompile it with more peer capacity limit (changing it from 4096 to maybe 8192). I'll try to test it while I'm on my easter break.

[TCROC]

@SoftwareGuy All good! No need to be sorry. I hope everything is okay IRL. No rush. Take all the time you need.

[SoftwareGuy]

Alright, I've modified the native library code in the ENet-CSharp repository to have a limit of 8191 peers, but I need to do some modifications to the versioning since I forgot it won't trigger a build unless a version tag is activated, which will require an micro-update to Ignorance. I'll do that by end of the day I guess...