Client-server communication: solved!

After some searching (http://www.gamedev.net/topic/659071-sending-and-receiving-udp-packets-to-character-status-need-be-encrypted/, and other) testing I got a good architecture for client-server communication. It’s something very close to the exposed solution in post Adversities in client-server communication (https://vectortowns.wordpress.com/2014/07/31/adversities-in-client-server-communication/). I will comment on the details here.

First I should clarify that this communication will only work if met with premises security and login (ie, a handshake). See the following:

1- At first, the player will send a TCP packet over SSL with your username and password. In the authentication process, a certification authority (CA) will be consulted to ensure the authenticity of the game server;
2- After confirmed the authenticity of the server, the client obtains a public key server;
3- The client generates a secret key (AES 128) and a sessionId and sends to the server by encrypting the packet with the server’s public key;
4- Thereafter all packets exchanged between them (either TCP or UDP) will be encrypted and decrypted with the secret key (AES 128).

After this handshake, the communication will be as shown in the following image:

Below are the details of communication:

– The client application is built in Java; the recipient of requests (which I call SuperServer) is built on NodeJS; the application of business rules (manage an NPC, for example) will be built (not yet exist) in Lua (http://www.lua.org/about.html) and is called ManagerServer; only SuperServer and ManagerServer applications communicate with the MySQL database;
– Every event (WALKING, CASTING, TALKING …) sent by a player occurs by a UDP datagram encrypted with AES 128 and 32 CRC checksum;
– For events that require confirmation, the response will occur via a UDP datagram checked with CRC 32 unencrypted. Note: An event like WALKING, for example, needs a server validation; one as LOGOFF, is sent only and has no return;
– All events logged by other players are obtained for the TCP socket without encryption;
– Sending events from Java client to NodeJS SuperServer occur by 9731 port; Java client application get events from other players by SuperServer 9732 port; Communication between the SuperServer NodeJS and ManagerServer Lua will occur by 9730 port.

With this architecture I’m getting a good performance. Sending events from Java application client to NodeJS server and your confirmation is performed in the range of 130-155ms. Obtaining the events of the other players is occurring in the range 180-200 ms. As there is an intentional delay of 200 ms for the game to run the events controlled by the player (same happens in the game Age of Empires 2) the sending and receiving of data occur at the expected time – without causing lag in game.

In the near future I will post here a video of the game with some online testers!

lol
bye

Domain registration

I hired a designer to do the game symbol. The work is going great. When trying to register the domain, I noticed that there is a site vectortown.com. I thought about registering as .net or gamevectortown.com, but the designer has convinced me that if we changed the name to Vector Towns would be even better.

In hindsight, the point of view of the game history (which I have not mentioned to you), Vector Towns would be even better than the singular name. So now the game will be called Vector Towns. The domain has been registered and the future points to a website. For now he just point to this blog (which also had its name changed).

Thanks for reading.