Skip to main content

Introduction

ionet

Lightweight lock-free asynchronous and event-driven architecture; nanosecond-level distributed communication without any third-party middleware
Built on a lock-free shared-memory ring buffer, fundamentally avoiding kernel mode switching and lock contention for ultra-low latency
Small package size, fast startup, low memory footprint, more cost-efficient, configuration-file free, with elegant route access control
Supports multiple connection types at the same time: WS, UDP, TCP, etc.; full-chain call tracing is built in
Use one business codebase to switch and extend data protocols easily: Protobuf, JSON
Near-native performance; the business framework executes an average of 11.52 million operations per second in a single thread
Code is integration documentation; JSR380 validation; assertion + exception mechanism = lower maintenance cost
Intelligent same-process affinity; during development, business code can be located and jumped to quickly
Flexible and diverse architecture deployment: services can be independent or tightly integrated
Write once, integrate everywhere; generates interactive client-side code
Logic services can communicate across processes and across machines
Supports dynamic player-to-logic-service binding
Can integrate and coexist with any other framework
Friendly for WebMVC developers
No strong dependency on Spring
Zero learning cost
JavaSE

JDK 25
JDK 25
AGPL3.0

Vision​

Make programming distributed network communication servers easy and simple. Change the status quo, lower adoption difficulty, and democratize productivity in network programming.

Launch Snapshot​

The framework also performs well in memory usage, startup speed, and package size.

  • Memory: low footprint.
  • Packaging: about 15MB after building the JAR.
  • Startup speed: applications typically start in 0.x seconds.

start

Introduction​

Do you want to build a high-performance, stable, easy-to-use, load-balanced, class-explosion-avoiding, cross-process and cross-machine, stateful multi-process distributed network communication server? If yes, here is a Java-based distributed network programming framework: ionet.

ionet is an open-source, lightweight distributed network programming framework based on Aeron, capable of nanosecond-level end-to-end latency.

Its internal message transport layer uses Aeron + SBE, delivering true zero-copy, zero loopback, zero reflection, zero GC, zero runtime parsing, and near-zero encoding/decoding overhead. Through a lock-free, shared-memory ring-buffer design, it fundamentally avoids kernel/user context switching and lock contention, which is the key to ultra-low latency. With extreme CPU efficiency, message processing speed can approach the hardware limit.

ionet is an open-source lightweight distributed network programming framework, suitable for:

  • Online game servers
  • Internet of Things (IoT)
  • High-frequency market data push
  • Real-time competitive interaction: online game engines
  • Telecom systems requiring high-performance data processing
  • Internal service communication with extreme latency requirements
  • Real-time stream data processing (such as video streams and sensor data)
  • High-frequency trading, market data distribution, and order processing (with extremely strict latency requirements)

The framework has the following characteristics:

  1. Truly lightweight, lock-free asynchronous, event-driven architecture.
  2. Small artifact size, low memory usage, and fast startup.
  3. The framework is pure Java SE, enabling easy integration with other frameworks such as Spring, Vert.x, Quarkus, Solon, and more.
  4. Very low learning cost, effectively zero learning cost. Even without game programming experience, developers can get started easily. With ordinary Java methods or WebMVC knowledge, developers can build business logic.
  5. In terms of lightweight design, the framework can provide nanosecond-level distributed communication without any third-party middleware, requiring only a Java runtime.
  6. The architecture supports elastic scaling; both external services and logic services can be dynamically added and removed.
  7. For distributed development experience, ionet supports running multiple services in a single process, making distributed development and debugging simpler.
  8. In ecosystem planning, logic services can run independently, enabling functional modularization.
  9. Full-chain call tracing is built in.
  10. Multiple communication methods are provided, and logic services can communicate across machines.
  11. In coding style, it provides an MVC-like pattern (non-intrusive Java Bean), which effectively avoids class explosion.
  12. For thread safety, it solves single-user concurrency issues for developers.
  13. For transport, developers can use one business codebase to support TCP, WebSocket, UDP, and more, without any code modification, and with extensibility.
  14. For data protocols, developers can use one business codebase to switch between protocols like Protobuf and JSON, with extensibility.
  15. For protocol addition/removal, you can add or remove protocols without restarting external services, avoiding both user disconnections and full-cluster restarts.
  16. action supports auto boxing/unboxing of primitive types to solve protocol fragment issues.
  17. The business framework includes a pluggable, extensible plugin mechanism.
  18. Deployment supports both multi-service single-process and multi-service multi-process multi-machine modes, and switching deployment mode does not require code changes.
  19. For security, logic services do not need exposed ports, naturally reducing scan-attack risk.
  20. For simulated client testing, it provides a pressure-test and client-simulation module. This module simulates real network conditions, and server interactions are continuous, interactive, and automatable.
  21. The framework provides synchronous, asynchronous, and async-callback methods for communication between logic services.
  22. Distributed event bus support (similar to MQ/Redis pub-sub), with cross-machine and cross-process communication.
  23. Elegant route access control.
  24. Intelligent same-process affinity.
  25. JSR380 validation + assertion + exception mechanism = lower maintenance cost.
  26. Write once, integrate everywhere: major productivity gains with interactive client code generation. You only need to write Java code once to generate unified interaction interfaces for Godot, UE, Unity, CocosCreator, Laya, React, Vue, Angular, and more.

ionet is an open-source lightweight distributed network programming framework that can achieve sub-microsecond or even nanosecond-level end-to-end latency. With extreme CPU efficiency, message processing speed can approach hardware limits.

The framework also performs well in packaging size, memory footprint, and startup speed. The packaged JAR is about 15MB, applications usually start in 0.x seconds, and memory usage is low.

For ecosystem integration, the framework can integrate with Spring very easily (4 lines of code). Besides Spring, it can also integrate with many other frameworks, such as Vert.x, Quarkus, Solon, and more.

Learning cost is very low, effectively zero learning cost. Even without network programming experience, developers can get started quickly. With ordinary Java methods or WebMVC-related knowledge, developers can build business logic with this framework.

In coding style, the framework provides an MVC-like pattern (non-intrusive Java Bean), effectively avoiding class explosion. At the same time, it provides synchronous, asynchronous, and async-callback methods for inter-service access. This makes code elegant and provides full-chain call tracing.

For client integration, the framework supports write once, integrate everywhere and provides code-generation assistance that significantly reduces client-side workload. That means you only need to write Java code once to generate unified interaction interfaces for Godot, UE, Unity, CocosCreator, Laya, React, Vue, Angular, and more. The framework provides multi-language SDK support and related code generation, including C#, TypeScript, GDScript, C++, Lua, and extensibility.

Architecturally, the framework solves the N*N problem found in traditional architectures (comparison with traditional architecture). Traditional architectures often require many third-party middlewares such as Redis, MQ, ZooKeeper, etc. to scale. Usually, once scaling requires installing external middleware, the architecture is no longer truly lightweight.

For lightweight design, the framework supports distributed network communication without any third-party middleware, requiring only a Java runtime. This means simpler usage and lower enterprise deployment/maintenance costs. With ionet, one dependency gives you the full framework without installing extra services such as Nginx, Redis, MQ, MySQL, ZooKeeper, or Protobuf compiler tools.

Regarding architectural flexibility, the architecture consists of external services and logic services. These can be independent or combined. This means the framework can adapt to any game type by adjusting deployment topology. Such adjustments are easy and do not negatively affect existing code.

The architecture supports elastic scaling; both external services and logic services can be dynamically added or removed. Whether user count grows or shrinks, the system can respond smoothly. At the same time, the architecture supports user-unaware updates, thanks to distributed design. For example, if A-type logic services need new features, you can start A-3 and A-4 with new features, then gradually take A-1 and A-2 offline to complete a seamless rolling update.

In distributed design, logic services are split into layers such as external services and logic services, and each layer has clear responsibilities and interfaces. This improves readability and maintainability and enables easy horizontal scaling.

In distributed development, multiple processes are usually required. This makes debugging and troubleshooting difficult, reducing developer efficiency and increasing workload. Many frameworks cannot solve this well, but ionet does. ionet supports running multiple services in a single process, making distributed system development and debugging much easier.

In terms of ecosystem planning, logic services can run independently. After startup, they can provide functional extension and enhancement for users and other logic services. We can componentize logic services into reusable modules, making functional modularization possible. This has several advantages:

  1. Avoid repeated development work.
  2. Reduce coupling between functional modules.
  3. Better align with single-responsibility design by splitting common capabilities into dedicated functional logic services such as guild service, friend service, login service, lottery service, announcement service, ranking service, and more.
  4. Since module capabilities are independent, any functional logic service can be scaled later without code changes.
  5. These componentized logic services are like a growing arsenal. Once accumulated, they become your ecosystem advantage in market competition.
  6. Lower code leakage risk. Traditional monolithic projects put all code in one place. If code leaks, the whole project leaks. With modularized services, each developer can work on their own logic service module, reducing leakage impact.
  7. Team administrators only need to deploy gateway + external services in internal infrastructure, while developers can code and test their own logic-service modules locally. Additional benefits:
    • Clients do not disconnect because another logic service changes or restarts.
    • Developers do not need to start other teammates' logic-service modules.
    • Developers can use framework-generated docs for module integration.

The framework provides full-chain call tracing, which is highly practical in distributed systems. It assigns each request a unique identifier and records it in logs, so request-level filtering is fast and precise. This tracing is powerful and supports cross-machine and cross-process scenarios. In short, from request entry to completion, no matter how many logic services are traversed, the trace can be accurately recorded.

For communication, most frameworks only support push (broadcast). This framework provides multiple communication models. By combining different models, many previously difficult scenarios become simple, and all these models support cross-process and cross-machine communication with full-chain tracing.

  • From the client perspective, the framework provides these communication models
    • request/response, request/response
    • request/void, request/no response
    • request/broadcast, request/broadcast response
    • broadcast, broadcast
  • Internal communication is mainly for server-to-server, cross-service, and cross-process communication. The framework provides these models

For thread safety, the framework solves single-user concurrency issues for developers. Even after reconnection, the same user's business can still be consumed on the same thread, and domain events are recommended to handle concurrency among multiple users in the same room or business context. The framework offers strong thread scalability, making lock-free concurrent programming easier through its unique thread executor design and extensions. In other words, you do not need to struggle with concurrency issues.

For lock-free concurrency, the framework provides an elegant and unique thread-executor design. With this feature, developers can easily write lock-free high-concurrency code.

For transports, the framework allows developers to use one business codebase and simultaneously support multiple transport types with no modifications. It already supports TCP, WebSocket, and UDP, and supports flexible switching among them. Transports are extensible, and extension is simple. If KCP or QUIC is supported later, you can switch from TCP/WebSocket/UDP to KCP/QUIC without changing existing business code.

For data protocols, developers can use one business codebase to switch and extend different data protocols, such as Protobuf and JSON. With just one line of code, you can switch from Protobuf to JSON without changing business methods.

For protocol add/remove, you can add or remove protocols without restarting external services. This avoids user disconnects and avoids full-cluster restart pain during protocol changes.

For protocol fragments, action supports automatic boxing/unboxing of primitive types to solve protocol fragment issues. This not only makes business code clearer, but also significantly improves productivity in this area.

For developer experience, the framework strongly emphasizes DX. It provides JSR380 validation, assertion + exception mechanisms, and business code location/debugging, as well as automatic boxing/unboxing for protocol fragments, and more. These rich features make business code cleaner and more concise.

The business framework provides a plugin mechanism, with pluggable and extensible plugins. Built-in plugins include DebugInOut, action invocation statistics, business thread monitoring, time-segment invocation statistics, and more. Different plugins focus on different concerns; by combining invocation and monitoring plugins, for example, teams can identify performance issues during development. With proper plugin usage, problems can be found and prevented earlier.

For deployment, the framework supports both multi-service single-process and multi-service multi-process multi-machine deployment modes, and deployment mode can be switched freely without code changes. In daily development, you can work with a monolithic mindset; in production, you can selectively deploy with multi-process modes.

For security, logic services do not need exposed ports, naturally avoiding scan attacks. Since each logic service does not require an independent port, when using cloud services you avoid many port-permission hassles. These seemingly small details often consume disproportionate engineering time. Because no IP:Port management is needed here, that workload naturally disappears.

For simulated client testing, the framework provides a pressure test & simulated client request module. This module simulates clients and reduces simulation workload: you only need to write request and callback logic. Beyond simple requests, it supports complex request orchestration and complex business pressure testing. Unlike unit tests, this module simulates real network conditions, and interactions with the server remain continuous, interactive, and automatable.

Using ionet can significantly reduce enterprise cost. In this documentation, the keyword cost appears many times and is connected to every stage, including learning, R&D, testing, deployment, scaling, and investment. Under equivalent resource competition, this framework can help companies save more resources and improve survival capability. More importantly, it reduces the chance of building value that mainly benefits other companies. See the cost analysis case.

Projects built on this framework are usually well-organized, thanks to the framework's reasonable routing design, and its elegant access control for routes. After modules are organized, project handover and long-term maintenance become easier (code organization and conventions). You may not feel the full impact immediately, but the deeper you practice, the more advantages you will see.

Projects built with this framework are typically concise in syntax, high-performance, and low-latency. The framework requires at least JDK25, allowing projects to benefit from Generational ZGC and cleaner syntax. Generational ZGC keeps pauses far below sub-millisecond targets, reclaiming memory without harming throughput. This helps avoid stalls or crashes, effectively like having a JVM tuning expert built into your project.

In summary, this framework is highly suitable for online game development. It helps you build high-performance, low-latency, and easily scalable servers while saving time and resources. If you want to build impressive online games quickly, choose this framework now. It hides complex and repetitive work, and provides clear organizational definitions for module structure and development flow, reducing long-term maintenance cost.

The framework provides strong support across all phases: development, deployment, client integration, pressure testing, and simulation. By now, you likely have an initial understanding of the framework. Although many features were not covered here, you can explore them through practice. Thank you for reading, and we look forward to seeing you build your own game servers with this framework.

Write Once, Integrate Everywhere, and Unlock Massive Productivity​

ionet strongly emphasizes developer experience, following the principles that code comments are documentation and methods are interaction interfaces.

The framework supports write-once-integrate-everywhere, significantly improving team productivity. Write once means writing Java business code once, while integrate everywhere means generating server interaction code for different frontend projects.

You only need to write Java code once to generate unified interaction interfaces for Godot, UE, Unity, CocosCreator, Laya, React, Vue, Angular, and more.

The framework can generate interface code for actions, broadcasts, and error codes for various frontend projects. That means one business codebase can interact with all these game engines and modern frontend frameworks.

Several advantages of frontend code generation

  1. Greatly reduces client-side workload and eliminates large amounts of template code.
  2. Clear semantics. Generated interaction code clearly defines parameter types and whether the server returns values, and this is explicit at generation time.
  3. Clear interaction interfaces ensure type-safe and explicit method parameters, so potential issues can be found at compile time. This approach effectively avoids safety risks and reduces low-level mistakes during integration.
  4. Reduces communication cost between client and server teams. Code is documentation. Generated integration code includes docs and usage examples, enabling even beginners to reach zero learning cost.
  5. Helps client developers abstract server interaction details so they can focus more on real business logic.
  6. Reduces cognitive load in integration. Integration code is simple and as smooth as local method calls.
  7. Replaces traditional protocol-oriented integration with an interface-method-oriented integration style.
  8. Once Java code is completed, docs and interaction interfaces are updated in sync, without extra time spent maintaining integration docs.

ionet Components​

ionet consists of a [Network Communication Framework] and a [Business Framework]

Business Framework

The business framework is designed to simplify business logic implementation and help developers start writing business code quickly.

For each action, the framework combines patterns such as Singleton, Flyweight, and Command. Action lookup is performed via arrays, which is close to native style. In single-threaded execution, the business framework can execute an average of 11.52 million business operations per second.

Business Framework JMH Performance Report - Click to Expand

jmeter

The data above is from single-threaded testing. The business framework executes an average of 11.52 million operations per second.

Architecture Overview Diagram​

Lock-free asynchronous and event-driven architecture; truly lightweight. You can build a distributed network communication server without any third-party middleware.

Built-in load balancing, distributed support, and dynamic machine scale-out/scale-in.

NameScaling ModeResponsibility
ExternalServerDistributedResponsible for user connections and interaction
LogicServerDistributedResponsible for specific business logic processing

ionet


From this architecture overview, we know the overall architecture consists of external services and logic services. They can run independently or be integrated together.

For a more detailed explanation, see Architecture Introduction.

External services and logic services use distributed design and support running multiple instances of the same service type. This means when user volume increases, we can easily add more instances of the corresponding logic-service type to handle more requests.

Taking logic services as an example: assume we start two A-type logic services, A-1 and A-2. When users send multiple requests to A-type logic services, the framework uses the default random load-balancing strategy to distribute requests between A-1 and A-2.

As shown, both external services and logic services support dynamic addition and removal. Whether user volume grows or shrinks, we can respond smoothly. The architecture supports user-unaware updates because of distributed design. For example, if A-type logic services need new features, we can start A-3 and A-4 with those features, then gradually take A-1 and A-2 offline, achieving seamless updates.

In addition, the framework supports dynamic binding to logic services. Once a user is bound to a logic service, subsequent requests are handled by that bound service.

ionet is also suitable for IoT-related projects. If you regard users in the diagram as physical devices, even hundreds of millions of devices can be supported by ionet architecture.


External Services

The main responsibility of external services is to establish long-lived connections with users. If one machine can support up to 5000 connections and your user count reaches 7000, you can add another external-service node to split traffic and reduce pressure.

By increasing the number of external services, you can effectively balance connection load and control traffic, allowing the system to handle high concurrency better. Because external-service scaling is simple, supporting millions or tens of millions of concurrent users becomes practical.

Even if multiple external services are running, developers do not need to care which external service a user is connected to. Users will always receive broadcast (push) messages, because the framework handles this for you. From the user perspective, there is only “one” server. Likewise, from the developer perspective, there is only “one” external-service layer.

Some developers often ask: what is the maximum number of user connections external services can support? For this question, search Netty-related knowledge, because external service connection handling is implemented with Netty. Likewise, if a developer is already familiar with Netty, extending external services becomes very easy.

Quick Start​

Below is a simplified diagram of business interaction between the game engine and game server.

Business interaction overview

Abstractly speaking, frontend-server interaction in games is represented by the diagram above. Frontend and server can perform bidirectional interaction freely, sending and receiving business data. Business data uses .proto files as the carrier for encoding and decoding between frontend and backend. A .proto file is a description carrier for business data, defining data types, message types, and their attributes and rules.

In this way, frontend and server establish connections and start exchanging business data for their own processing. The above is the interaction overview between frontend and server. Next, we will write a simple business-processing example and customize a business data protocol suitable for our needs.

A protocol file is a description carrier for business data used in frontend-server interaction. Protocol Buffers is a data description language developed by Google, often abbreviated as PB. Protocol descriptions can also be JSON, XML, or any custom format, because transmission is ultimately binary. In game development, PB is currently the best option.

Game frontend presentation can be Godot, Unity, UE, Cocos Creator, Laya, FXGL, or other game engines. These engines are only presentation forms; data interaction is handled by communication protocols (TCP, UDP, etc.).


Data Protocol

Now we define the data protocol used for client-server data interaction. If your background is mainly web development and not game server development, you can think of this as DTO/business data carriers used for data transport.

Since native PB can be relatively cumbersome to use, we use JProtobuf here. It simplifies PB usage while keeping performance equivalent to native PB.

Adding the ProtobufClass annotation to a regular Java class means it is a business data protocol object.

@ProtobufClass
public class UserMessage {
    public int id;
    public String nickname;
}

Action

After the server receives business data, it processes the data. The following code simultaneously supports TCP, WebSocket, and UDP communication.

@Slf4j
@ActionController(1)
public class HallAction {
    @ActionMethod(0)
    private UserMessage loginVerify(String message) {
        var userMessage = new UserMessage();
        userMessage.nickname = "Jack";
        return userMessage;
    }
}

A method (loginVerify) represents an Action (business action) in the business framework. The method parameters receive request data from the client, and the returned data is sent back to the requester. This means developers do not need to care about internal framework details.

As shown above, this is no different from an ordinary Java class, and this design avoids class explosion. If your focus is only writing business logic, this is enough to start using the business framework.

tip

Network programming can be this simple!


Q: Can I start building network game servers now?

Yes, you can start now.


Access Example (Console)

When accessing an action business method, the console logs are printed as follows.

┏━━ Debug.(HallAction.java:18) ━━ [UserMessage loginVerify(String jwt)] ━━ [31-1] ━━ [tag:HallLogicServer, serverId:5656645] ━━━━
┣ userId: 1378604058
┣ RequestParam: Michael Jackson
┣ ResponseData: UserMessage(id=1378604058, nickname=Jack)
┣ ExecutionTime: 1 ms
┗━━ [ionetVersion] ━━ [Thread:User-8-1] ━━ [ConnectionWay:WebSocket] ━━ [traceId:1761556037925] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Console output explanation

  • code 1:
    • [Debug.(HallAction.java:18)]: the executed business class is HallAction, and 18 is the line number of the business method. Click HallAction.java:18 in the console to jump directly to the corresponding source code (quick code navigation). This is a core DX feature.
    • [UserMessage loginVerify(String jwt)]: the executed method, including method parameters and return type.
    • [31-1]: the route of this request.
    • [tag:HallLogicServer]: logic service information that executed this request.
  • code 2: current requester userId.
  • code 3: request parameter passed by requester.
  • code 4: response value that the framework pushes back to requester.
  • code 5: total execution time of the business method, useful for optimization.
  • code 6:
    • [ionetVersion]: current framework version.
    • [Thread:User-8-1]: thread used to execute the action.
    • [ConnectionWay:WebSocket]: connection type used by the user's external service.
    • [traceId]: full-chain tracing id (very useful in distributed scenarios).

With this information, developers can locate issues quickly. Without this kind of observable information, development wastes significant time on frontend-backend communication. Typical issues include:

  • Is it a request-parameter issue? (request side says parameter was sent)
  • Is it a response issue? (backend says response was returned)
  • Is it an execution-time issue? (request side says no response; backend says response was sent earlier)

Code navigation lets developers jump quickly to corresponding business class code. In collaborative projects, it helps quickly understand which methods were executed in a business flow, enabling fast reading and modifications.

Multiple Aspects the Framework Focuses On​

Every framework labels itself with terms like high performance, ease of use, learnability, and extensibility. Here we explain several core aspects that are also most frequently encountered in development:

  1. Performance: internal network communication performance and business framework performance.
  2. Development: developer experience, parameters, parameter validation, exception handling, and debugging.

Performance

ionet consists of a network communication framework and a business framework, so we focus on the two most frequently used points.

  • Network transport performance: the upper performance limit of network transport depends on Aeron. The internal message layer uses Aeron + SBE and achieves nanosecond-level end-to-end latency.
  • Business framework: in single-threaded execution, actions can process an average of 11.52 million business operations per second.

Development

ionet places strong emphasis on developer experience, with near-zero learning cost. Development includes several sub-areas: developer experience, parameters, parameter validation, exception mechanisms, and debugging.

1. Developer experience

  • Zero learning cost: an ordinary Java method is an action.
  • Method parameters are request parameters from the requester.
  • Method return values (response results) are sent back to the requester.

As shown below, the framework abstracts away communication details. This makes development simple, effectively zero-cost to learn (because it is just an ordinary Java method), and this design avoids class explosion.

@ActionController(1)
public class DemoAction {
    @ActionMethod(1)
    private UserMessage jackson(LoginVerifyMessage message) {
        ErrorCode.nameChecked.assertTrue("Jackson".equals(message.jwt));

        var userMessage = new UserMessage();
        userMessage.name = "hello Jackson";
        return userMessage;
    }
}

// ErrorCode
public enum ErrorCode implements ErrorInformation {
    /** Name check */
    nameChecked(100, "The name must be Jackson");
    final int code;
    final String message;

    ErrorCode(int code, String message) {
        this.code = code;
        this.message = message;
    }

    @Override
    public String getMessage() {
        return this.message;
    }

    @Override
    public int getCode() {
        return this.code;
    }
}

@ProtobufClass
public class LoginVerifyMessage {
    public String jwt;
}

@ProtobufClass
public class UserMessage {
    public String name;
}


2. Parameters

The framework has friendly support for JProtobuf communication protocols. Here, communication protocol refers to business data transfer between client and server. For example: login request (client -> server), login response (server -> client).


3. Parameter validation with JSR380 (method parameter validation)

The framework supports JSR380 validation specifications. Business parameter validation no longer needs to be written directly in business logic, which keeps business code cleaner. Without a validation framework, the usual approach is excessive if/else checks in business code, which makes code messy.


4. Exception mechanism

Assertion + Exception mechanism = clear and concise code

The business framework supports exception handling, making business code cleaner. This exception mechanism is also a key reason why ordinary Java methods can become actions with near-zero learning cost.

If there is a business exception, throw it directly. Developers do not need extra handling logic. The business framework knows how to process business exceptions, and these exceptions will always be returned to the requester.


5. Debugging (method invocation)

During development, the framework provides request-access logs and business code location, a powerful feature. It lets you know which business methods were invoked and quickly jump to the corresponding business code.

Code navigation allows developers to quickly jump to the corresponding business class code. In multi-developer projects, you can quickly understand which methods were executed in a business flow, enabling fast reading and modification.

Built-in Framework Features​


Multiple optional built-in modules are available and can be selected as needed to support application development:

  1. Domain Events: a lightweight single-machine ultra-fast MQ model. It can provide capabilities similar to Guava EventBus and Spring ApplicationEvent, help business decoupling, avoid concurrency conflicts, and avoid blocking the main thread.
  2. Generate .proto from JProtobuf: allows multiple objects to be generated into the same .proto file.
  3. Pressure test & simulated client requests: simulates real network conditions. During integration with frontend developers, you no longer need repetitive "click again" coordination.
  4. Room module for tabletop/room-style games: a solution for room-based game architectures. Suitable for projects like Hearthstone-like games, SanGuoSha-style games, poker, mahjong, and other room-based experiences such as CS-like matches, Bomberman-like games, flight chess, tank battle games, etc.
  5. Frontend code generation: write Java code once and generate unified interaction interfaces for Godot, UE, Unity, CocosCreator, Laya, React, Vue, Angular, and more.

Other built-in capabilities:

  1. Heartbeat-related features
  2. User online/offline hook methods
  3. Login-related features, including login, account takeover handling, duplicate-login prevention, etc.
  4. Built-in Kit, providing dynamic properties, property listeners, timeout tasks, timer simulation, task scheduling, delay tasks, and lightweight controllable delayed task capabilities.

Summary​

This document is similar to a book's preface or outline. In general, most points mentioned in this introduction have corresponding detailed sections elsewhere in ionet documentation.

tip

This document is important. Do not skim it too quickly (haste makes waste). Sometimes fast is slow, and sometimes slow is fast.

This brief introduction provides an overall framework-level picture. It is important, contains many cross-links, and is worth reading carefully more than once.