Choices

From CatchChallenger wiki
Jump to: navigation, search

You have here all general choices. To choices specific to the client/server, see the correct page.

Datapack

Full datapack on the client

Other choices

The partial datapack is send when you want keep hand of the content. Because it's harder to reproduct, but not impossible (l2jfree). The text of the bot is downloaded at live from the MMORPG server, add then increase the bandwith, lower the performance, slow down the game.

We choices

We idea is trust of the user (an user witch wishes reproduct the datapack will do it, same for found crack of no free game). And don't block the creativity. Allowing the full datapack downloading, permit to do unstoppable project (if the server close, anyone can reopen new because have the datapack), and you can play as standalone local game with your datapack from favorite MMORPG server.

Lost into the battle

To do easy load teleport, the teleport after lost a battle is do by normal teleport. Reason:

  • More easy on server part
  • Not frequent, then latency on that is acceptable.

Text not binary

The free structure allow better organisation, but is more slow. Minor impact on server. Only partial datapack is directly loaded on client, can be improved compiling the ressources, but before that's improve the xml loading (Slow by multiple small file? Cache?).

Client

Path finding

To minimize the cost of the infrastruture, we do an unique algorithm: not the sortest path but the path with less direction changing. Minimise the network bandwith, minimise the context switch to improve the performance (as OS part and application part).

Stat

The stat is get from login to offload the master, prevent overload the bandwith between login and master by transmiting ip/geo of the client.

Protocol

Message size on each packet (web socket)

The unique case where do that's it's very bad it's when you have multiple very small packet aggregated. I will try never do that's. And for very small trafic the overhead will be 30% but 1KB transmited or 1.3KB it's same.

At exchange of that's you don't have hash table and the packet speed is boosted by 10x.

With drop subcode, the table is into 256Bytes, and the performance in C is correct to don't add the size, then don't add the size for tcp socket (not web socket).

The fixed size (always 32Bits) is for have defined offset to boost the packet composing.

Max player

The max player is not fixed size to minimize the bandwidth (lot of individual small packet). Then you have at each code part:

 if(max player<=255)
   do 8Bits cast
 else
   do 16Bits cast
  • Why not only 255? Because is too low to organize big event, and lot of player will feal it too limited.
  • Why 65535 max player? Because 255 is supported but not the max, and the other value is not the best.
  • Why not 4 billions of players? Because most of MMO server don't have more than 200 000 players, then nearest of 65535 than 4 billions. At this scale, lot of hardware don't scale well, no hardware support 4 billions (lack of memory, include in multi core the Instructions per second is too poor to support it, without speak about the network interface limit). The overhead of 32Bits entry is huge at network scale (Mostly double the bandwidth), and it's better do multiple server than one big server.