Understanding Netty’s Asynchronous Model, Epoll, and IO Multiplexing – From Theory to a Hand‑Written Server

Netty is introduced as a powerful asynchronous network framework whose performance stems from a pure async model, built‑in codecs, heartbeat detection, and efficient handling of sticky packets. The article likens Netty to the legendary Sword in the Stone, urging readers to "pull" the epoll sword for high‑throughput services.

Netty’s Asynchronous Model

The classic multithread model creates a dedicated thread per client, which quickly exhausts memory under heavy load. Netty replaces this with the Reactor pattern, where an Initiation Dispatcher (the Reactor) demultiplexes events and forwards them to Handlers that execute business logic.

Two key participants are described:

Reactor : dispatches I/O events to appropriate handlers, similar to a telephone exchange.

Handlers : perform specific tasks such as authentication, heartbeat checking, or protocol decoding.

Various Reactor evolutions are illustrated with diagrams: single‑thread Reactor, pooled Reactor, and multi‑Reactor (mainReactor + subReactor) which maps directly to Netty’s bossGroup and workerGroup .

JNI Integration

The article shows how Netty’s native transport (e.g., transport‑native‑epoll ) uses Java Native Interface (JNI) to call C code for maximum performance. A minimal Java class DataSynchronizer and its native method syncData are presented, followed by the steps to generate header files, implement the C function, compile a shared library, and invoke it from Java.

public class DataSynchronizer {
    static { System.loadLibrary("synchronizer"); }
    private native String syncData(String status);
    public static void main(String... args) {
        String rst = new DataSynchronizer().syncData("ProcessStep2");
        System.out.println("The execute result from C is : " + rst);
    }
}

#include
#include
#include "DataSynchronizer.h"
JNIEXPORT jstring JNICALL Java_DataSynchronizer_syncData(JNIEnv *env, jobject obj, jstring str) {
    const char *inCStr = (*env)->GetStringUTFChars(env, str, NULL);
    if (NULL == inCStr) return NULL;
    printf("In C, the received string is: %s\n", inCStr);
    (*env)->ReleaseStringUTFChars(env, str, inCStr);
    char outCStr[128];
    printf("Enter a String: ");
    scanf("%s", outCStr);
    return (*env)->NewStringUTF(env, outCStr);
}

Compilation commands using javac -h . and gcc -fPIC -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/linux" -shared -o libsynchronizer.so DataSynchronizer.c are provided, followed by execution with java -Djava.library.path=. DataSynchronizer .

IO Multiplexing Models

The article reviews the evolution from the early select API (bitmap limited to 1024 fds) to poll (array of struct pollfd without the 1024 limit) and finally to Linux’s epoll , which uses a kernel‑resident data structure (interest list + ready list) backed by a red‑black tree for O(log N) updates and O(1) ready‑list traversal.

Key system calls are described:

epoll_create – creates an epoll instance.

epoll_ctl – adds, modifies, or deletes file descriptors (EPOLL_CTL_ADD/DEL/MOD).

epoll_wait – blocks until ready descriptors appear.

Level‑Triggered vs Edge‑Triggered

Level‑Triggered (LT) notifies as long as a descriptor is ready, which is simple but generates many wake‑ups under high concurrency. Edge‑Triggered (ET) notifies only on state changes, reducing kernel‑user transitions but requiring the application to drain the socket until EAGAIN is returned.

Sample output demonstrates the difference: LT repeatedly prints when data remains in the buffer, while ET prints only once per edge.

Hand‑Written Epoll Server (C)

A complete, well‑commented epoll server implementation (~200 lines) is presented. It includes functions to set non‑blocking mode, add descriptors to the epoll instance with optional ET flag, and separate processing loops for LT ( lt_process ) and ET ( et_process ). The main function creates a listening socket, registers it with epoll, and enters an infinite epoll_wait loop.

#define MAX_EVENT_NUMBER 1024
#define BUFFER_SIZE 10
#define ENABLE_ET 0
int SetNonblocking(int fd) { ... }
void AddFd(int epoll_fd, int fd, bool enable_et) { ... }
void lt_process(struct epoll_event* events, int number, int epoll_fd, int listen_fd) { ... }
void et_process(struct epoll_event* events, int number, int epoll_fd, int listen_fd) { ... }
int main(int argc, char* argv[]) { ... }

The server can be compiled with gcc -o epoll_server epoll_server.c -pthread and run to handle thousands of concurrent connections, demonstrating the practical performance gains of ET mode.

Performance Outlook

While the article mentions that achieving a million concurrent connections requires additional OS tuning (e.g., file‑descriptor limits, TCP backlog, NUMA awareness), it emphasizes that the core epoll‑based design already provides the scalability needed for such workloads.

References

Java Native Interface – https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html

"The Method to Epoll’s Madness" – https://copyconstruct.medium.com/the-method-to-epolls-madness-d9d2d6378642

Finally, the author adds a personal note encouraging readers to like and share the article.