Limiting TCP/IP traffic

User avatar
Kruell
Posts: 254
Joined: Thu May 26, 2016 10:35 pm

Limiting TCP/IP traffic

Postby Kruell » Fri May 27, 2016 5:10 pm

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.
If you look like prey you will be eaten

User avatar
NiteHawk
Site Admin
Posts: 3120
Joined: Wed Apr 20, 2016 7:33 am

Re: Limiting TCP/IP traffic

Postby NiteHawk » Fri May 27, 2016 5:20 pm

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.


Return to “Archive Chat”

Who is online

Users browsing this forum: No registered users and 27 guests

cron