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: AuthServiceHandler, JumpServiceHandler, and GameServiceHandler. Each of these classes inherits from HandlerBase. 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 AuthServiceClient, JumpServiceClient, and GameServiceClient classes.

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 AuthServiceHandler class.

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) =>
Connect.CallMethod<AuthenticateResult>(AuthMethods.Authenticate, parameters);

The value 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 AuthMethods enum.


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