MMORPG Theory

[Canning]

In a MMORRPG, there is a lot of data exchanged between the server and clients. I am wondering if I should compress this data before sending it over a tcp connection. It greatly reduces the size of the data, I am just wondering if it is efficient. Would it use too many resources on the server side?

[leghola]

Hi,

In a network game, you must use TCP & UDP systems. The TCP system is the best because it had the particularity to control the good receipt of the message BUT TCP is slower than UDP. The, when you have a message that no be crucial, you can use the UDP.

Example :
- Connection message, chat message, interaction message => TCP
- Position message => UDP

Position messages are send a lot of time per minutes then if the system lost one of them it's not a problem.

For the server, he had 2 main tasks :
1. Control the connections and security
2. control the stability of the world

For example, a player hit a monster. He launch a message to the server : [Message Number 5555 : PlayerX, Target MonsterY, Action Hit]. The server analyze the possibility of the action and send a message to the player like this : [Message Number 5555 : Result OK].

Nico.

[Canning]

Thanks.

But that doesn't solve my question... should I compress data when I send it from the server to the client? Will it put too much of a strain on the processor at the server end?

[leghola]

Humm... my personal answer is no..

Why ? Because the server MUST analyze a lot of messages and if he need to compress/uncompress for each of them, it can take a lot of time and resources.

the only thing (i think) is to create messages as short as possible.

nico

[Canning]

OK, thanks.

Canning

[Canning]

Just another question... how much faster is UDP? I am wondering if I should implememnt it as u say, for player positions.

[micmanos]

UDP is faster in the sense that ....

1. It uses a headerless (well not exactly but it's much smaller) packet which reduces the size.

2. It's connectionless, meaning you can start sending out packets towards anyone (don't expect the other one to receive it tho) without the need to establish a formal handshake/link.

3. Contrary to the TCP, it will not wait for confirmation, that the data were delivered and received, thus will not engage in any activities to resent/correct the error.

... but it's not faster in the sense that it magically makes data travel faster. The bandwidth limit is the same for both.

[Hypnotron]

UDP is faster in the sense that ....
3. Contrary to the TCP, it will not wait for confirmation, that the data were delivered and received, thus will not engage in any activities to resent/correct the error.

In addition to #3, packets can arrive in any order (eg. not in the exact same order in which they were sent).  With TCP on the other hand, packets _must_ always arrive in order so if one packet is delayed, any other received packets will not be readable until the missing ordered packet that is next to deliver to your application arrives.  Thus the tcp/ip stack will continue to receive data but not pass it on to your app until that one missing packet arrives.

These two aspects of TCP (guaranteed arrival and in order) is what makes UDP faster in the practical sense of writing some types of game netcode.  That's because certain types of games like shooters don't need 100% perfect data transmission nor ordered transmission.  It's faster to create your application's communication protocol to be tolerant of missing packets and then just ignore out of order packets and to not worry about missing packets than it is to wait on tcp to resend missing packets.