Page 1 of 1

Limiting TCP/IP traffic

Posted: Fri May 27, 2016 5:10 pm
by Kruell
Not sure how your settings are now so this might not be a problem. I'm going on my own experience coding for Alura and working on RoK though for anticipating trouble. With the use of macro's, you will have some people just holding the buttons most of the time. If/when events happen, you could have dozens of people simply holding a macro button down the entire time. Without some limitations placed on the broadcast traffic of the client, the server can easilly be overwhelmed and "lagged out" at key moments.

We tried a novel solution in Alura hoping to get rid of lag that caused other problems using a first in/first out approach but the resulting processing delay allowed for the command to attack person A reaching the server right before the same command from A on B. The server would determine the attack on A would kill them and they would die... but their command for an attack on B would still be there resulting in the dead killing their slayer. Just throwing out one of the problems we ran into when trying to control the macro traffic push. That was like 12 years ago though so by now I hope there are easier options.

Re: Limiting TCP/IP traffic

Posted: Fri May 27, 2016 5:20 pm
by NiteHawk
Kruell wrote:Not sure how your settings are now so this might not be a problem. I'm going on my own experience coding for Alura and working on RoK though for anticipating trouble. With the use of macro's, you will have some people just holding the buttons most of the time. If/when events happen, you could have dozens of people simply holding a macro button down the entire time. Without some limitations placed on the broadcast traffic of the client, the server can easily be overwhelmed and "lagged out" at key moments.

We tried a novel solution in Alura hoping to get rid of lag that caused other problems using a first in/first out approach but the resulting processing delay allowed for the command to attack person A reaching the server right before the same command from A on B. The server would determine the attack on A would kill them and they would die... but their command for an attack on B would still be there resulting in the dead killing their slayer. Just throwing out one of the problems we ran into when trying to control the macro traffic push. That was like 12 years ago though so by now I hope there are easier options.


At the moment clients can send up to about 10 messages per second. It delays about 100MS, but it's a little shorter depending on how long it took the function to process. (I.E. if a function took 5ms to process, it will wait 95ms instead so the uniform wait is 0.1MS) It's on a easy to configure setting so if I need to increase it I can, but it's fine for now.

Each socket is on it's own thread so they shouldn't hurt themselves too bad either. They place nicely with each other right now anyways in regards to how it's processed. With the delay above and this it tends to ensure everyone gets data always.