lag Reduce Lag

[elexis]

The github branch should be linked in #3700. 0AD does use enet, but the more crucial part is the way C++ interacts with JS. It uses the SpiderMonkey JS engine. The C++ NetClient and NetServer receive data either as strings, integers or some JS variable. The latter are saved in a ScriptInterface (just some place that holds all variables).

You could start by reading NetServer.cpp and NetClient.cpp and trying to figure out what happens there. There are only a dozen of network message types with 0-4 variables each (handshake, chat message, game start command, ingame command, rejoin command and so forth, see NetMessages.h).

> If net server is only in another thread of same process, their isnt any connection between host and main client, or am i wrong?

The connection is via network, just like every other client, except that its the local ip 127.0.0.1, so you get like 6ms latency instead of 200-500ms (average to barely acceptable ping).

However if the client freezes (i.e. that one thread doing everything is stuck in some kind of infinite or extremely long loop, such as "sunken ship lag"), the server will continue to perform while the client doesn't. Since the NetClient runs in the same thread as the renderer and simulation (which is the freezing part), then it won't get cycles to process and send the net packets, thus loses the connection to the server running in the separate thread (while possibly no other client loses the connection).

[Stan`]

@JuKu96 ticket is #3700 you can find the diff in there. If you need any assistance feel free to ask here.

Well threads communicate like peer so if one is stuck the other can lose connection to it.

[JuKu96]

thanks for your help!

 

On 30.10.2017 at 6:33 PM, elexis said:

The github branch should be linked in #3700. 0AD does use enet, but the more crucial part is the way C++ interacts with JS. It uses the SpiderMonkey JS engine. The C++ NetClient and NetServer receive data either as strings, integers or some JS variable. The latter are saved in a ScriptInterface (just some place that holds all variables).

You could start by reading NetServer.cpp and NetClient.cpp and trying to figure out what happens there. There are only a dozen of network message types with 0-4 variables each (handshake, chat message, game start command, ingame command, rejoin command and so forth, see NetMessages.h).

> If net server is only in another thread of same process, their isnt any connection between host and main client, or am i wrong?

The connection is via network, just like every other client, except that its the local ip 127.0.0.1, so you get like 6ms latency instead of 200-500ms (average to barely acceptable ping).

However if the client freezes (i.e. that one thread doing everything is stuck in some kind of infinite or extremely long loop, such as "sunken ship lag"), the server will continue to perform while the client doesn't. Since the NetClient runs in the same thread as the renderer and simulation (which is the freezing part), then it won't get cycles to process and send the net packets, thus loses the connection to the server running in the separate thread (while possibly no other client loses the connection).

 

On github their isnt any branch, except master.

But i see you use newest version of enet.

0 A.D. is using UPD protocol, or isn't it?

 

Is there an replacement / alternative to spidermonkey?

Also i think it will be an better idea to use queues for receiving and sending messages... This will make multi-threading an little bit easier.

I think i should start with improving the documentation while reading NetServer.cpp and NetClient.cpp, as you said...

 

> The connection is via network, just like every other client, except that its the local ip 127.0.0.1, so you get like 6ms latency instead of 200-500ms (average to barely acceptable ping).

why was so decided? Isn't it an unneccessary overhead? Or should server always standalone?

 

> then it won't get cycles to process and send the net packets, thus loses the connection to the server running in the separate thread (while possibly no other client loses the connection).

thanks! I understand the problem now.

 

On 30.10.2017 at 7:06 PM, stanislas69 said:

@JuKu96 ticket is #3700 you can find the diff in there. If you need any assistance feel free to ask here.

Well threads communicate like peer so if one is stuck the other can lose connection to it.

Hmmm...

I think this wasnt an good design descision, because this causes most of lag.

Most games today doesnt work like peer anymore...

[Imarok]

1 hour ago, JuKu96 said:

Most games today doesnt work like peer anymore...

Which type of games are you talking about? (The network architecture heavily depends on the game genre)

[Stan`]

@JuKu96

Quote

Is there an replacement / alternative to spidermonkey?

Yes, there is google's javascript engine V8, but there is no reason to make the switch.

Quote

Also i think it will be an better idea to use queues for receiving and sending messages... This will make multi-threading an little bit easier.

I think i should start with improving the documentation while reading NetServer.cpp and NetClient.cpp, as you said...

Looking forward to see what you'll come up with.

[elexis]

The github repository or branch of andy5995 contains the net threading code (not the official github mirror).

The local client works like every other client. Besides having the advantage of being able to put the server on some other machine, it also means actually having less complexity, as there is only one mechanism that servers every player equally. 127.0.0.1 networking overhead is completely negligible.

Replacing spidermonkey with something else will be as simple as changing about every file.

0ad uses the enet protocol which implements reliable communication via UDP. The lobby part works via xmpp.

enet does use peer vocabulary and easily allows p2p communication, but don't let that vocabulary fool you - the 0ad protocol still implements a NetServer and a NetClient, i.e. a star architecture / hierarchy https://en.wikipedia.org/wiki/Star_network. The single point of failure issue is addressed by every clients hashing the simulation state and thus being able to determine that noone is messing with the gamestate (otherwise the hash fails and people can assume to not really play in the same gamestate anymore).

"Reduce lag" -> Forget about the networking unless we're talking about a some special kind of situation that shows up as actual network lag in the top right hand corner. (Though lost packets should also be displayed there sometime). The 0AD game stuttering happens just as well in singleplayer and replay mode often because there is more data to process than the CPU can handle. There are only few kilobytes sent via network (the commands, no state).

[JuKu96]

I have discovered also an interesting article, how age of empires resolved some problems:
https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

 

19 hours ago, elexis said:

The 0AD game stuttering happens just as well in singleplayer and replay mode often because there is more data to process than the CPU can handle.

Okay. Then we should use more multi-threading in simulation, or?

CPU clock speed will be reduced in future and number of cores will be increased. So this problem will also increase with newer CPUs.

[elexis]

If one is particularly interested in networking, the said improvements are still valid. But the main performance issue is making the pathfinding able to thread and running the renderer independently from the simulation.

There are similar design documents about 0AD and the developers took inspiration from AoE design documents like this too. Actually I think exactly that one was (or could have well been) part of it.

[vladislavbelov]

4 hours ago, JuKu96 said:

Okay. Then we should use more multi-threading in simulation, or?

Multi-threading has own overhead: more complicated code (may crash and dead-locks) and time to sync data between threads/processes. So it needs to be very carefully.

Btw, I have some ideas about a threaded rendering.

[andy5995]

On 11/2/2017 at 12:33 PM, JuKu96 said:

On github their isnt any branch, except master.

 

The branch is on my fork: https://github.com/andy5995/0ad/tree/issue_3700

[JuKu96]

Thanks!
But i cannot work on it yet, because of university.

I cannot work on this until march.

[JuKu96]

Are all changes mirrored to github? Or is this only an outdated state?

[Imarok]

18 minutes ago, JuKu96 said:

Are all changes mirrored to github? Or is this only an outdated state?

It is max 1 day off.

[DylanT]

My tip is if you want to reduce lag, don't play in online mode. If you play in online mode, there are hundreds of players with hundreds of troops, so there would definitely be lag.