Why is only TCP used?

[Andreas XXL]

Why is is only TCP used?
Does it make sence to send a missing massage for example the health status of a unit with the same information again?
In the time it can be changed in the run of the game...

I think perhaps some of the problems of Multiplayer game are from that.



Same in german, I can speak that better
Das gleiche auf deutsch, das kann ich besser

Warum wird nur TCP verwendet?
Wenn man den Status einer Einheit (z.B. Lebenspunkte) versendet und dieses Paket kommt nicht an, dann wird das gleiche Paket bei TCP so lange erneut versendet bis es tatsächlich ankommt. In der Zwischenzeit kann sich aber der Status der Einheit im Spielverlauf schon verändert haben.
Bei UDP würde das fehlende Paket einfach ignoriert werden beim nächsten Abgleich sofort ein neues Paket mit dem aktuellen Werten geschickt.

Ich habe das Gefühl das einige Probleme bei Mehrspielerpartien daher kommen.

[Kamaze]

UDP has just the advantage of a lower latency, which doesn't really mind in an RTS game. TCP offers a lot of benefits, for example, it guarantees that the packages arrive and in the correct order. This are thing you need to take care of manually, if using UDP.

Also, as far as I know, there are no packages like "Health status of unit x". I think Warzone has the same simulation running on every client, so the clients can and will calculate them self which unit has which status. So, only game "commands" are send, like "Ordered truck to build building" or "ordered unit x to move to z" etc...

Problems are de-syncs, afaik. Which means that the simulation of one client differs from the rest, or (worst case) all client simulations start to differ. Recovering from a desync is not an easy task and may require still some tweaking.

[Andreas XXL]

Was always TCP used or was it changed from UDP during the development process?
(In the development in the resurrection Project)

[Zarel]

UDP has just the advantage of a lower latency, which doesn't really mind in an RTS game. TCP offers a lot of benefits, for example, it guarantees that the packages arrive and in the correct order. This are thing you need to take care of manually, if using UDP.

Wait, Warzone uses TCP? Why?

"All packets in correct order" doesn't help an RTS - as long as they're timestamped, it doesn't matter if you know whether some guy researched MG first or moved their truck first. On the other hand, "all packets arrive and in the correct order" means that if a single packet gets delayed, all packets are delayed, and if it's delayed more than 2000ms, the game is disconnected. No wonder players disconnect so often in MP games!

An RTS doesn't need low latency as much as, say, an FPS, but it's definitely more important than in an RPG. And TCP offers no benefits at all, as far as I can tell, and far too many drawbacks.

You have to realize that in UDP, on the order of 99.9% packets get delivered - it's easy enough to resend the failed packets.

[Kamaze]

"All packets in correct order" doesn't help an RTS - as long as they're timestamped, it doesn't matter if you know whether some guy researched MG first or moved their truck first.

From my knowledge this would stall the game simulation and produce out-of-syncs, if warzone uses the simulation approach as I expect. And yeah, you can "implement" TCP behaviour to some degree in UDP, but if TCP already offers the features you may need, why re-invent the wheel? (As long as it's not hyper-time-critical) However, EvilGuru is the netcode lord. Maybe he has some final words.

[EvilGuru]

You have to realize that in UDP, on the order of 99.9% packets get delivered - it's easy enough to resend the failed packets.

Funnily enough that is the case for TCP as well — except it takes care of resending packets for us.

On the other hand, "all packets arrive and in the correct order" means that if a single packet gets delayed, all packets are delayed, and if it's delayed more than 2000ms, the game is disconnected.

TCP is very, very, cleaver about this. A lot of research has gone into so call congestion avoidance algorithms (http://en.wikipedia.org/wiki/TCP_conges ... _algorithm ) whose purpose is to decide how many packets to send without a response. This number is based off of things such a previous experiences, but varies between algorithms.

Quite often if a single packet is delayed all packets will be delayed (packets are delayed for a reason, such as broken connections). So UDP would be of no use here, either. At least with TCP after delays of 1000ms+ (possible if the route between you and the server changes due to a hub going down) there is a much better chance of having a usable gamestate once all of the packets are resent. Since Warzone is very low bandwidth these can easily be bursted.

UDP offers no benefits. The pings obtained by the current netcode are more than sufficient. When they are not it is more than likely that there is an underlying problem with the connection that renders any game un-playable, TCP or not.

Furthermore the order does matter. Consider the case of building a unit and then having it automatically move to a rally point. Or constructing a droid within range of an enemy target.

Moreover by using TCP we do not need to worry about a) creating too many packets, as the OS handles packet construction for us; b) the size of individual packets. While this type of 'corking' is not suitable for an FPS it is for an RTS.

In conclusion: TCP was simpler to use, easier to debug (it is stateful) and presents no real latency issues.

On a side note: UDP is useful to FPS games because of the network model that they use. In this model the entire state is stored on the server, which several times a second creates a new 'state'. The server also maintains a list of previous states and what state each client has. Bringing the clients up-to-date is just a case of computing the delta (difference) between the most recent state the client is known to have and the current state.

The beauty of this is that all the client needs to do is see if the state the server is sending it is newer than its current state and if so update itself and send a response. In this model any packet can be lost (clients acknowledgement, state delta...) without issue.

Of course, Warzone being peer-to-peer with regards to game state can not make use of this model and therefore UDP is of no advantage.

Regards, Freddie.

[Zarel]

[excellent explanation of TCP]

Thanks. I'm sorry if I was a bit rude earlier; I'm a bit too used to the "UDP == gaming" mindset.

On a side note: UDP is useful to FPS games because of the network model that they use. In this model the entire state is stored on the server, which several times a second creates a new 'state'. The server also maintains a list of previous states and what state each client has. Bringing the clients up-to-date is just a case of computing the delta (difference) between the most recent state the client is known to have and the current state.

The beauty of this is that all the client needs to do is see if the state the server is sending it is newer than its current state and if so update itself and send a response. In this model any packet can be lost (clients acknowledgement, state delta...) without issue.

Of course, Warzone being peer-to-peer with regards to game state can not make use of this model and therefore UDP is of no advantage.

Hmm, but Warzone does have a central server for each game - it's not completely peer-to-peer. While I don't know that much about networking, from your explanation it seems that the FPS network model could be used in Warzone, too, and may alleviate some of the sync issues we have.

[EvilGuru]

Hmm, but Warzone does have a central server for each game - it's not completely peer-to-peer. While I don't know that much about networking, from your explanation it seems that the FPS network model could be used in Warzone, too, and may alleviate some of the sync issues we have.

Currently each player is in charge of its own units state. It is the authority on them. Only you know what you're producing in your factories, no one else. The information is just not sent.

The FPS style model requires the centralised server to be the ultimate authority on everything about the current state of the game. This would require moving a lot of code around (although it would be a beneficial change). Currently to get the game state at a time, t, you need to ask every client about its own units and combine them together. For the FPS model to work clients must find out about their own units from another computer — the server.

But yes, it would solve almost all sync issues and also make it possible to detect/prevent cheating. (As you would just send commands such as 'build this' to the server, rather than every other player taking your word for it.)

Regards, Freddie.

[Kamaze]

While I don't know that much about networking, from your explanation it seems that the FPS network model could be used in Warzone, too, and may alleviate some of the sync issues we have.

If you want to get into this topic, there is an interesting article from the Age of Empires developers about networking in a RTS game: http://www.gamasutra.com/features/20010 ... ano_01.htm

[Andreas XXL]

I looked at the code for about 2 hours and i found that:

http://developer.wz2100.net/browser/tru ... ultisync.c


#define STRUCT_FREQUENCY 450 // how often (ms) to send a structure check.
#define DROID_FREQUENCY 300 // how ofter (ms) to send droid checks
#define POWER_FREQUENCY 10000 // how often to send power levels
#define SCORE_FREQUENCY 25000 // how often to update global score.

Here is the check time for the power level. It is done every 10 seconds.
I think it is easy possible to detect energy cheaters here. If for example the check detects a difference of 10000 to the last check a cheat is used.
If the differences to the last check are stored in a file (Textfile so a human can read it), every player can easy check if he played with a energy cheater. He only needs to look if the differeces are extremly high.


It often happens that you start a game and you get 1000000 energy from a teammember. You know he is cheating. But if you say nothing the enemy does not know this. But the enemy could know it, if a file with stored energy levels differences exists.

What you think about that?

[Zarel]

The FPS style model requires the centralised server to be the ultimate authority on everything about the current state of the game. This would require moving a lot of code around (although it would be a beneficial change). Currently to get the game state at a time, t, you need to ask every client about its own units and combine them together. For the FPS model to work clients must find out about their own units from another computer — the server.

But yes, it would solve almost all sync issues and also make it possible to detect/prevent cheating. (As you would just send commands such as 'build this' to the server, rather than every other player taking your word for it.)

Well, we already have a centralized server (the host), it just isn't the ultimate authority on everything yet. We would indeed have to move a lot of code around, but we all know that the current netcode is at least an 8.5/10 on "likelihood of causing permanent sanity loss" - I could spend hours just ranting about turnOffMultiMsg()...

I think we should change to this model.

Here is the check time for the power level. It is done every 10 seconds.
I think it is easy possible to detect energy cheaters here. If for example the check detects a difference of 10000 to the last check a cheat is used.
If the differences to the last check are stored in a file (Textfile so a human can read it), every player can easy check if he played with a energy cheater. He only needs to look if the differeces are extremly high.

Yes, we should definitely use this as a short-term solution. Total power shouldn't increase by more than a certain limit per 10 seconds.

[EvilGuru]

What about people donating power? A simple solution can suddenly become very, very, complicated.

Regards, Freddie.

[Zarel]

What about people donating power? A simple solution can suddenly become very, very, complicated.

That's why I said "total power". For no-alliances games, we can just keep track of each individual player. For locked teams games, we can just keep track of total power per team. For free alliances mode, we can just keep track of total power for everyone.

[Per]

While there are some simple tricks we can add to detect the most rudimentary cheating, it won't help much. Once we add such checks, cheaters will adapt and go just enough under the radar that their cheats cannot be distinguished from off-sync bugs. For example, since each player is authoritative about his own units, he can cheat to ignore all damage done to them. Or you can send blow-up-die packets for enemy units just for the heck of it. There is just no way to verify it automatically right now.

I'd rather we create a "Hall of Shame" forum thread about those who do cheat.

[Zarel]

I'd rather we create a "Hall of Shame" forum thread about those who do cheat.

This, um, isn't going to help at all. People can change usernames, you know. And it's not like the unscrupulous type who cheat will feel particular mental anguish about having one of their made-up names on a list.