Networking rewrite, need help
Moderator: Moderators
-
- Posts: 12
- Joined: 16 May 2009, 19:14
Re: Networking rewrite, need help
I realize this thread is idle -- but I was just taking an interest to reading it. Recognizing that this isn't really a topic about the code -- but if additional optimization can be done from a network perspective.
Has someone measured the network packet traffic off of a Spring server and applied the Hurst Parameter to the packet load? Can someone summarize the network traffic sources in Spring?
From my vantage point as an end-user -- I am deducing this:
Centralized server implementation to relay traffic...
Clients update server with actions from players
Server maintains global information and determines game state
Server broadcasts results to each client
As a result...
Sources of network traffic:
Real-time action and coordinate information.
Real-time messaging (during game and in the lobby).
Broadcast in-game text messaging.
Entire maps from server .
Potential future sources:
Broadcast in-game voice messaging.
Customized spray images from players.
Most firewalls/routers today are by default designed for bulk data transfer -- which is anti-intuitive to real-time the type of gameplay Spring utilizes. Spring (in my guess) would be better suited on hardware that can handle sustained bursts at millisecond levels (prolly utilizing buffers that make use of ECM, AQM) while utilizing smaller packet sizes and shorter queues. Has anyone thought through this?
Regards,
Polaris
Has someone measured the network packet traffic off of a Spring server and applied the Hurst Parameter to the packet load? Can someone summarize the network traffic sources in Spring?
From my vantage point as an end-user -- I am deducing this:
Centralized server implementation to relay traffic...
Clients update server with actions from players
Server maintains global information and determines game state
Server broadcasts results to each client
As a result...
Sources of network traffic:
Real-time action and coordinate information.
Real-time messaging (during game and in the lobby).
Broadcast in-game text messaging.
Entire maps from server .
Potential future sources:
Broadcast in-game voice messaging.
Customized spray images from players.
Most firewalls/routers today are by default designed for bulk data transfer -- which is anti-intuitive to real-time the type of gameplay Spring utilizes. Spring (in my guess) would be better suited on hardware that can handle sustained bursts at millisecond levels (prolly utilizing buffers that make use of ECM, AQM) while utilizing smaller packet sizes and shorter queues. Has anyone thought through this?
Regards,
Polaris
Re: Networking rewrite, need help
Yes.Centralized server implementation to relay traffic...
Clients update server with actions from players
No.Server maintains global information and determines game state
Server broadcasts results to each client
All the server does is broadcast the received client commands (unit orders, player chat messages, ...) back to every client; each client determines its local next simulation state independently based on what it gets from the server. Commands are the _only_ source of network traffic.
Re: Networking rewrite, need help
commands are the only source of engine traffic - but lua messages can do stuff like allycursor and lockcamera, don't forget about those
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Networking rewrite, need help
Thats the reason CA has about 3 times more traffic per player than BA.imbaczek wrote:commands are the only source of engine traffic - but lua messages can do stuff like allycursor and lockcamera, don't forget about those
Re: Networking rewrite, need help
Current system seems to be performing well. I would prefer it over full p2p one.
And yes, you can send 30 commands/second. Dont forget clients have lua, for example auto swarm can easilly spam tens of orders per second.
EDIT: wtf i seem to have posted without reading till end of this thread :) Probably missed next page button :)
And yes, you can send 30 commands/second. Dont forget clients have lua, for example auto swarm can easilly spam tens of orders per second.
EDIT: wtf i seem to have posted without reading till end of this thread :) Probably missed next page button :)
Re: Networking rewrite, need help
a host backup would be nice to have, but currently everything else seems fine.
Re: Networking rewrite, need help
Games where host fails are extremely rare, especially with autohosts or "automatic dedicated server" feature from springlobby.
Re: Networking rewrite, need help
Atm we dont know whats causing 3x more traffic for CA..and recently its much more. I suspect that some incorrect widget spams lua messages.Auswaschbar wrote: Thats the reason CA has about 3 times more traffic per player than BA.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: Networking rewrite, need help
It would be interesting to see a breakdown of network usage by subsystem and widget like that CPU usage breakdown display.
Also, are Spring's packets fairly readable in Wireshark? I remember some guy did a Wireshark analysis of Spring's packet traffic a few years back and noticed some weird behavior around the order queuing system. It would be interesting to Wireshark a few games on one of the bigger autohosts and analyze it.
Also, are Spring's packets fairly readable in Wireshark? I remember some guy did a Wireshark analysis of Spring's packet traffic a few years back and noticed some weird behavior around the order queuing system. It would be interesting to Wireshark a few games on one of the bigger autohosts and analyze it.
Re: Networking rewrite, need help
Demo file Ôëê packet stream.
Re: Networking rewrite, need help
Yeah, wiresharking is only useful if you really want to debug the resends and stuff like that.
The actual data can just be read from the demo stream.
The actual data can just be read from the demo stream.
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Networking rewrite, need help
I suggest using the demoanalyser.
Its in the spring git repo. Pass a demo to it and it will examine all the messages passed, printing a message log. It can be easily extended to do whatever analysis you want, I just added traffic statistics, thought.
Its in the spring git repo. Pass a demo to it and it will examine all the messages passed, printing a message log. It can be easily extended to do whatever analysis you want, I just added traffic statistics, thought.
-
- Posts: 35
- Joined: 17 Sep 2008, 15:54
Re: Networking rewrite, need help
I am not a developer, but as I live in Australia, I often experience high latency.
For the most part Spring does an excellent job dealing with high-latency, 300-400ms is very playable.
The one annoyance I have is changing firing modes (return fire, etc), since cycling through them is affected by latency, so I am unable to "double-click" it to cycle twice, instead I must wait for the first cycle to succeed before cycling again.
For the most part Spring does an excellent job dealing with high-latency, 300-400ms is very playable.
The one annoyance I have is changing firing modes (return fire, etc), since cycling through them is affected by latency, so I am unable to "double-click" it to cycle twice, instead I must wait for the first cycle to succeed before cycling again.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Networking rewrite, need help
Yes I find this annoying as well when playing on a slow host (I have no latency problem, my internet uses photons).PhailQuail wrote:I am not a developer, but as I live in Australia, I often experience high latency.
For the most part Spring does an excellent job dealing with high-latency, 300-400ms is very playable.
The one annoyance I have is changing firing modes (return fire, etc), since cycling through them is affected by latency, so I am unable to "double-click" it to cycle twice, instead I must wait for the first cycle to succeed before cycling again.
Luckily this can be solved with a simple widget that overrides the firestate button, or others.