Migrating from ioGame

Introduction

Comparison with ioGame

Title	Description
Significant Performance Improvement	The framework's internal message transport layer uses the Aeron + SBE combination, with true zero-copy, zero loopback, zero reflection, zero GC, zero runtime parsing, and nearly zero encoding/decoding overhead. Through a lock-free design and a zero-GC strategy, it can achieve sub-microsecond or even nanosecond-level end-to-end latency. Especially in inter-process communication (IPC), performance can approach the hardware limit.
Simpler External Server Custom Protocol	ExternalMessage combined with the CommunicationMessage interface flattens logical attributes that do not need serialization into its parent class, so only one object needs to be created during external-server processing. The new solution has very low memory overhead, no temporary objects, zero GC, and completely avoids creating new Java objects during encoding and decoding.
Simplified Internal Protocol	The internal protocol uses a flattened design to reduce object creation.
Network Requests and Total Serialization Count	Analyze from several aspects: total serialized objects, total deserialized objects, total created objects, and total network requests. Under the same communication model, the request chain and forwarding chain are greatly reduced, and total serialization count is also significantly reduced.
Reduced Internal Network Hops	Thanks to the IPC mechanism, cross-process data interaction occurs only in memory and does not generate network requests.
Simplified Thread Model	A simplified thread model with no business thread context switching. Developers only need to focus on the business thread model, making custom orchestration easier.
Better Extensibility	It is easier to extend the communication model and retrieve data from the external server.
Examples	Provides more usage examples.

---

Differences from ioGame Architecture

ioGame uses an ExternalServer + Broker + LogicServer architecture.

Due to time and effort constraints, ionet currently uses an ExternalServer + LogicServer architecture plus a built-in registry center. Broker support may be added later when resources allow. This future support will not impact the existing architecture and can be introduced transparently.

Because ionet has IPC capabilities, there are no network requests between servers even when they run in different processes.

Why launch a new product

Why launch a new product instead of continuing iteration on ioGame? There are several reasons:

1. The internal transport layer changed from Bolt to Aeron, and not all developers are comfortable adopting new technologies immediately.
2. This transport-layer change also led to API changes. Backward-compatible support for old APIs would require additional work. Launching a new product avoids this compatibility burden and allows unrestricted refactoring and optimization.
3. Some enterprise users requested differentiated capabilities between enterprise and non-enterprise users.

How to migrate

In most cases, the current framework can still be compatible with ioGame-related code. The main differences are highlighted below.

Title	Description
Logic Server	Simplifies logic server creation.
Communication Model	Internal communication model APIs use unified and standardized naming, making them more intuitive.
Access External Server	Easier to extend and better support for unauthenticated users.
Thread Orchestration	Simplifies the thread model; developers only need to focus on the business thread model.
Room	Simplifies the Room extension module and reduces conceptual complexity.
Spring Integration	Spring-related parts are moved into extension modules, allowing developers to choose as needed.
Dual-Version Strategy	Adopts a dual-version strategy (Open Source Edition / Enterprise Edition) Open Source Edition: Streamlines distributed-related features, greatly lowering the entry barrier and reducing learning costs. It is committed to providing a high-performance solution for single-machine deployment. A single machine supports launching multiple processes, which is sufficient for most project needs. Enterprise Edition: Provides horizontal scalability through distributed deployment across multiple machines and nodes, breaking the physical limits of a single machine to support hundreds of millions of connections and ultra-high concurrency scenarios. In addition, the enterprise edition provides comprehensive feature enhancements and performance optimization for distributed scenarios, delivering seamless horizontal scaling.

tip

It is recommended to migrate together with the document examples. Other notes:

• Package names have been adjusted.
• Extension module naming has been unified with the extension prefix.

Final note

Developers are encouraged to migrate whenever possible, because future primary effort will focus on the current open-source repository.