Table of Contents
The communication with the server uses a low-level UDP-based protocol named Mercury. Mercury is described in detail in the document Server Overview's section Inter-Process Communication (Mercury).
Server communication is accessible from both C++ and Python scripts.
Note
This section is only applicable for a full client/server BigWorld implementation.
To log in, the client sends a UDP packet using Mercury to the login server, on a well-known port. The packet contains all the account and character information required to authenticate the client and select a character.
If login is successful, the login server adds an entity for the character to the BigWorld server system, and refers the client to a proxy server, which handles all in-game communication. Both sides then begin sending data to each other. For more details on the login process, see the document Server Overview's section Design Introduction → Use Cases → Logging In.
A Mercury channel is created between the proxy and the client. Only selected data that is classified as reliable is resent in the event of a dropped packet. Due to the average packet rate, and the expected network latency, a packet is classified as dropped if a packet with a higher sequence number is received before it is.
Since the client is operating in high-latency conditions, the server does not wait for dropped packets to be resent before delivering other pending information to the client. The client must therefore cope with receiving out-of-order messages of all kinds.
Messages are sent to the server through a ServerConnection class. The position of the player is sent to the server 10 times a second. Messages are received from the server by this class during the input loop, and dispatched to their handlers in the Entity Manager.
-
The types of messages that the server can send to the client are as follows:
-
enterEntity
Informs the client that the entity with the given ID has entered its AoI.
-
leaveEntity
Informs the client that the entity with the given ID has left its AoI.
-
createEntity
In response to a query from the client, provides the type and other immediate data of the entity.
-
avatarUpdate
Updates the position of an entity that has a volatile position.
These messages are sent unreliably (i.e., they are not resent if the packet is lost).
-
entityMessage
Sends a script message to, or updates a property of the client representation of an entity.
-
-
The types of messages that the client can send to the server are as follows:
-
avatarUpdate
Informs the position of the client's player entity to the server.
-
requestEntityUpdate
Requests information about the entity with the given ID that has just entered the client's AoI.
This works by effectively setting the entity's last update time (to the requesting client) to the time contained in this message.
Properties that have been changed since that time are resent.
-
entityMessage
Sends a script message to the server side of an entity (either on the base or on the cell).
-
The bane of mass-market online gaming is the firewall, especially the corporate ones. Our protocols have been designed to work smoothly through all but the most paranoid of firewalls.
From the firewall's point of view, it should appear that the client has initiated both the login and the proxy packet streams — since the login reply packet contains the address of the proxy server to send to, the client can immediately begin sending data, which makes it appear to the server it has initiated this stream too, i.e., it 'punched a hole in the firewall'.
The BigWorld server correctly handles the case where it sends data to the client (which may be lost if the client is behind a firewall) before the client has sent any data to it — the lost data is resent.
All that the firewall needs to support for these protocols to work is the storing of a UDP reply mapping entry when it forwards an outgoing packet, so that a when a reply packet arrives with exactly reversed addresses (the source and destination IP and port are swapped from the request packet), it is forwarded back to the requesting client. This is the same requirement as that of the ubiquitous Internet Domain Name Service (DNS), which practically all firewalls support.
The BigWorld server does not require the client to make requests from any particular port, so it is not confused if a firewall masquerades the port as well as the IP.