Bug/Issue: MDReplicator replication rate

[Beider]

I made a small example to test out my own code for my game clock with 10 moving objects that just rotated in a circle, for testing I used the Replicator on their position and scale. This caused each of the objects to pretty much spam one replicaiton call every frame. I also used clumsy to set 600 ping between the clients. Which I think hit some sort of limit because my clients started getting really bad ping to each other and packets were getting dropped.

I think a solution would either be to say that each value can only be replicated so often or perhaps a replication general cap where if you try to replicate more than X values in Y time you will get throttled and get errors in the log.

There seem to be a limit to how many calls you can do per second and we should probably make sure the framework respects this.

[DoubleDeez]

Wouldn't this fall under #10 with you UpdateInterval suggestion? I guess the part about respected the internal max rate is new

[Beider]

That update interval was a suggestion, this is an actual bug where if you replicate too many properties too fast your clients lag/die. I should probably have reflected that in the title.

I think an actual hard limit for the replicator across all the replication it does is needed. Something like it is only allowed to replicate 30 values every 0.1 second or so. That would give you 300 updates a second. I think I was doing 600-1200 a second when I encountered the problem. And you can reach that super quick with bad code, where you just slap replication directly on your position vector which updates every frame. Spawn a couple of such poorly coded nodes and the client just dies.

We could of course just say if someone is dumb enough to do so then it's their problem.

[DoubleDeez]

Gotcha, yeah I would like to help prevent things from breaking for people who may not have a full understanding of what's going on, we should fix this.

[Beider]

This has in some part been solved by #30 as we swapped Always replicate to Interval replicate, however that being said perhaps this would be best solved by introducing some sort of hard limit on how much we replicate. This could be done in scope of #32 as that issue is kind of related since it deals with balancing the network sending.

[DoubleDeez]

If this is fixed as part of #32, would we treat anything without a group as being in a fallback "DefaultGroup" group?

[Beider]

My current plan is to first of all switch to physic frames and that we choose how many frames we want between each update. Then I would have a manager that holds which things to send each frame, let's call each of these groups a FrameGroup

If a new custom group comes in I would just assign that to a FrameGroup and any further things that come in with the same custom group name would end in that FrameGroup.

If something that has no custom group comes in I would just look for the FrameGroup with the least values to be replicated and shove it into that group.

I think this should work out well for now, however we could make this more advanced if necessary where we measure how much data is actually sent and try to rebalance the FrameGroups if one group ends up sending a lot more than the others.

[DoubleDeez]

Is this still an issue with all the replicator changes?

[Beider]

I don't think it is a pressing issue, the problem was the constant replication per frame, so with the interval changes we can probably close this issue until we detect that this is a problem

[Beider]

Closing this as this is no longer needed.