Networking rewrite, need help

[polaris_silvertree]

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

[Kloot]

Centralized server implementation to relay traffic...
Clients update server with actions from players

Yes.

Server maintains global information and determines game state
Server broadcasts results to each client

No.

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.

[imbaczek]

commands are the only source of engine traffic - but lua messages can do stuff like allycursor and lockcamera, don't forget about those

[Auswaschbar]

commands are the only source of engine traffic - but lua messages can do stuff like allycursor and lockcamera, don't forget about those

Thats the reason CA has about 3 times more traffic per player than BA.

[Licho]

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 :)

[imbaczek]

a host backup would be nice to have, but currently everything else seems fine.

[Licho]

Games where host fails are extremely rare, especially with autohosts or "automatic dedicated server" feature from springlobby.

[Licho]

Thats the reason CA has about 3 times more traffic per player than BA.

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.

[el_matarife]

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.

[lurker]

Demo file Ôëê packet stream.

[Tobi]

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.

[Auswaschbar]

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.

[PhailQuail]

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.

[CarRepairer]

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.

Yes I find this annoying as well when playing on a slow host (I have no latency problem, my internet uses photons).

Luckily this can be solved with a simple widget that overrides the firestate button, or others.