High‑Performance Network Frameworks: IO Events, IO Multiplexing and the Reactor Pattern

1. Lonely Little Black

Last week Beijing was cold; DaBai received a WeChat message from his friend XiaoHei and went to the subway station, then rode a bike to Wudaokou where XiaoHei had chosen a good spot.

XiaoHei: You finished work early today!

DaBai: Work is everywhere, don’t be bound by form.

They discuss a recent interview at an autonomous‑driving startup, mentioning high‑performance network framework concepts such as IO and event‑driven models.

2. IO Events and IO Multiplexing

2.1 What is an IO Event

IO stands for Input/Output. The reference point is the program’s main memory; external devices include NICs and disks.

IO is essentially data flow between memory and devices.

Common IO types:

Network IO: memory ↔ NIC

File IO: memory ↔ disk

An IO event is a state change that triggers an action. Typical network IO events are readable, writable, and exceptional events.

2.2 What is IO Multiplexing

When thousands of IO events exist, the program registers them with the kernel via an IO‑multiplexing function; the kernel notifies the program when events change.

IO multiplexing lets a single thread listen to and manage many IO events because at any moment only a few events are active.

3. Network Framework Design Elements

A network framework must handle three major tasks: IO event listening, data copying, and data processing/computation.

IO event listening

Data copying

Data processing and computation

4. High‑Performance Network Framework Practice

4.1 Thread‑Based Model

The early "One Request One Thread" model creates a thread per request, which does not scale to thousands of concurrent connections.

4.2 Event‑Driven Model

Modern frameworks use an event‑driven IO‑multiplexing model, where an event loop waits for events and dispatches callbacks.

Event‑driven programming is a paradigm where external events drive program flow via a loop and callbacks.

4.3 Reactor Pattern

The Reactor pattern separates IO handling from business logic, often using a dedicated thread (or threads) for event demultiplexing and a thread pool for processing.

5. Reactor Pattern Details

5.1 Essence of the Reactor Pattern

All network frameworks perform two core operations: IO (read/write packets) and CPU work (process and package data). The division of labor among threads leads to different Reactor variants.

Single‑Reactor thread

Single‑Reactor thread + thread pool

Multiple‑Reactor threads + thread pool

5.2 Single‑Reactor Thread

One thread handles listening, accepting, reading, and writing. Simple but limited CPU utilization; suitable for in‑memory services like Redis.

5.3 Single‑Reactor + Thread Pool

The Reactor thread handles IO, while a worker pool processes the data, improving CPU usage but still limited by a single IO thread.

5.4 Multiple‑Reactor Threads + Thread Pool

Multiple Reactor threads share the load: one (or a few) for accepting connections, others for read/write, combined with a worker pool for processing, achieving higher scalability.

5.5 Extension: Synchronous vs Asynchronous IO

Reactor implementations typically use non‑blocking synchronous IO; true asynchronous IO (e.g., IOCP on Windows or Linux’s aio) can further reduce copying overhead via DMA and zero‑copy techniques.

6. Summary

The article starts from IO events and multiplexing, explains thread‑based and event‑driven network frameworks, details the Reactor pattern and its variants, and finally distinguishes synchronous and asynchronous IO, helping readers grasp the core concepts of high‑performance network architecture.