Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve sending of immediate orders #16052
If immediate orders are attached to a tick, they are completely ignored by the server. This is probably not the intended behaviour for server orders but I also can't see any reason to do that for any other type of immediate order.
The second commit makes sure that every immediate order ends up with its own framing. There is no reason to pack multiple immediate orders into a single framing and this change allows the server to process huge groups in pieces without reading everything at once.
From the IRC logs:
Can you please provide a link to your server source so we can understand this in more detail?
The server sends PingOrders in the lobby but also while playing. But because the official server doesn't do anything if it doesn't receive the PongOrders while playing (it actually receives them but ignores them due to another bug/strange assumption), you will never notice it. My implementation detects server orders slightly differently which caused it to detect the server order PDU with client orders in it as a regular server orders and thus didn't forward anything to the clients. This caused the game to freeze usually at tick 9 (sometimes around tick 100).
There are two differences in between server orders and client orders besides the name (some string) and the actual payload. The type field contains 0xFE for a server order PDU and 0xFF for a client order PDU (0xBF would be a disconnect PDU and 0x65 would be a sync PDU). If the type field is missing (see length field), then it is an empty client order PDU. There is also a tick field which is needed for client orders, disconnect and sync PDUs. It is currently always set to 0 when sending a server order (not really relevant for chat messages and stuff like that).
If server and client orders can end up in the same PDU (like they do at the moment), then the type field is obviously meaningless. The first commit splits immediate orders and regular orders into separate PDUs and the second commit splits all immediate orders into separate PDUs. The former is needed to avoid attaching immediate orders to a tick. The latter should make it robust in case some new type of "immediate client order" gets introduced in the future and also removes a very rare corner case from the protocol completely so that servers don't have to handle it.
My git server isn't public but I will try to attach a dump of the current code. But be warned that it is overly complex because it is designed to scale across multiple servers (mostly to reduce latency) and also partly because I used it to learn a new framework. Due to the way how the master server protocol works, the scaling requires anycasting which would be fine for UDP and short TCP connections, but isn't that great for OpenRA. This caused issues for some of the players where their ISP most likely did some sort of ECMP which is why I will drop the scaling functionality in the next rewrite/overhaul. It has some additional checks exactly for this bug and disconnect you with a link to this bug if you run into it (usually tick 9 or around tick 100) so you can use it as a testcase, if you want.