Extending Load Balancer Functionality
To expand the functionality of the Load Balancer, start by examining the
LoadBalancer.Server project. You will find three classes of interest:
GameServiceHandler. Each of these classes inherits from
HandlerBase serves as a base class, with subclasses created for individual client connections. Extending these subclasses is essential for introducing new functionality. When adding new methods or modifying existing ones on the server, remember to make the corresponding changes to the client-side wrappers. To achieve this, navigate to the
LoadBalancer.Client project and review the
When creating a new service, you can follow the pattern of an existing service like Auth, Jump, or Game. For a new service, implement a class derived from
ServiceBase. For instance, you can refer to the
AuthService class. This implementation is primarily responsible for the service’s Startup/Shutdown sequence and the instantiation of an appropriate handler for each connection. The core functionality of the service resides in the handler. The handler, which derives from
HandlerBase, contains methods that can be invoked from the client. For a comprehensive example of handler implementation, refer to the
Services can interact with each other using server-to-server communication implemented in the GC Core API. To facilitate this, one service acts as the caller, and the other as the called service. On the caller side, you need to implement a new class derived from
ServiceClientBase. An example is the
AuthForJumpServiceClient. On the called service side, server-to-server calls are managed by the same handler used for client calls. To distinguish between client-related methods and server-to-server methods, the example separates server-to-server methods into a separate partial implementation. Refer to the
AuthServiceHandler and its partial implementation under
LoadBalancer.Server -> Auth -> Jump -> AuthServiceHandler.cs.
Binding client methods to server methods can be achieved in two ways. The simpler approach involves using method names or method byte codes, depending on the chosen serialization approach (see Serialization). The example code provided combines both methods, allowing you to easily switch between them.
For instance, consider the method Authenticate in the AuthServiceClient of the LoadBalancer.Client project:
public Task<AuthenticateResult> Authenticate(AuthenticateParameters parameters) =>
AuthMethods.Authenticate specifies that the server will call the
Authenticate method in the
AuthServiceHandler class. For a string
KeyType, binding the name of the
AuthMethods.Authenticate enum to the
Authenticate method name would suffice. For a byte
KeyType, both the client-side
AuthServiceClient class and the server-side
AuthServiceHandler class possess an attribute
[MethodsEnum(typeof(AuthMethods))]. This attribute ensures that all methods called on the server from the client are listed in the
The attribute is unnecessary when using a string
KeyType, as binding by method name will occur automatically.
To register new serialization types, the
Bootstrapper class is employed. This class also registers all available services and initializes logging.
In the Unity example provided at the beginning of this topic, numerous configuration files are included. These files result in the server starting with three auth servers, two jump servers, and two game servers to showcase various capabilities of Load Balancer.
Configuration files named
config*.json are used to launch the server
gcs.exe with different configurations. For example, you can start all services in one process using
config.json. Alternatively, you can start each service instance in a separate process, employing the
config_ServiceName.json file format.
Service configuration files are named
settings*.json, with each setting file corresponding to an instance of the service.
Generally, you can press
F5 to run the server from Visual Studio shortly after opening the LoadBalancer solution. However, you may require the server to run in the background, such as for automated tests. To achieve this, a set of cmd files is available in the Solution items. These cmd files enable you to run all services in one process, run each service instance in a separate process, or