The Transport Server is a fundamental component of the Game Carrier ecosystem. It serves as a robust and scalable platform designed to host and manage a wide range of applications. Its primary function is to facilitate network communication between clients and the hosted applications, acting as an intermediary for data transmission.
The Transport Server provides a reliable and efficient network layer that enables seamless communication between clients and the various hosted applications. It handles the complexities of network protocols, data routing, and message delivery, allowing developers to focus on building their applications without having to worry about low-level network intricacies.
By utilizing the Transport Server, developers can leverage its capabilities to create and deploy diverse services and applications, such as game servers, authentication systems, matchmaking services, chat and communication modules, leaderboard and statistics trackers, and more. The Transport Server provides a centralized and scalable infrastructure that supports the smooth operation of these applications.
With its event-driven architecture, the Transport Server enables efficient and real-time communication between clients and hosted applications. It leverages a set of events and callbacks to handle connection establishment, data transfer, and session management. This event-driven approach ensures optimal performance and responsiveness, making it well-suited for interactive and multiplayer applications.
To support the hosting of applications written in different programming languages on the Transport Server, Game Carrier has developed specialized bridges known as Adapters. The purpose of adapters is to bridge the gap between the Transport Server’s underlying network layer and the specific requirements and syntax of different programming languages. They provide a standardized interface that allows applications written in languages such as Python, C#, and others to interact effectively with the Transport Server.
Adapters handle the translation and transformation of data and messages between the application and the Transport Server, ensuring compatibility and smooth communication. They abstract away the complexities of language-specific networking details, enabling developers to focus on building their applications without having to deal with low-level networking intricacies.
It’s important to note that Adapters are not necessary for applications designed as native libraries (e.g.,
dylib, etc.). The server can effortlessly load these native libraries without requiring additional components.
By utilizing adapters, developers can leverage the features and capabilities of the Transport Server regardless of the programming language they are using. This promotes flexibility and interoperability, allowing applications written in different languages to seamlessly communicate with the Transport Server and other hosted applications.
The diagram presented below illustrates the structure of the interacting elements:
The example of the event-based communication logic between the client and applications hosted on the Transport Server looks as follows:
- To establish a connection, the client needs to utilize the IP address, port, and unique identifier of the game application hosted on the server.
- During the connection phase, the server triggers the corresponding on_connect() event. As part of this event, the server assigns a unique session identifier to the client, which facilitates ongoing communication.
- Once the connection is established, the client can employ the gc_client_add_message() function to transmit data from the client to the application hosted on the server.
- The game application retrieves the client’s messages, triggering the on_connect() event. The client’s message includes the session’s unique identifier, enabling the server to reply with the corresponding data and maintaining the game process.
- When the client receives data from the server, the corresponding on_client_message() event is triggered.
- If the client decides to end the session with the game application hosted on the server, it can initiate the closure by calling the gc_client_stop() function.
- Upon receiving the message, the server triggers the on_disconnect() event, closing the connection with the client.