High-throughput, service-oriented C++ middleware
From embedded systems to high-performance distributed applications

Most C++ projects don't fail on algorithms. They fail on threads, IPC, and brittle integration code.
Areg SDK eliminates that category of failure — and does it without sacrificing throughput.

• Why Areg SDK
• How It Works
• Performance
• Areg SDK vs. Alternatives
• Getting Started
• Architecture
• Network Deployment Model
• Use Cases
• Roadmap
• Documentation
• License
• Community

• Do threading and synchronization issues slow your development velocity?
• Is your IPC integration fragile, hard to test, or hard to extend?
• Does moving a component from in-process to out-of-process require rewriting its interface?
• Do you lose hours debugging silent failures when a service restarts unexpectedly?
• Is your distributed system difficult to monitor and diagnose in production?
• Are you building a data-intensive pipeline where framework overhead must be near zero?

If you answered yes to three or more — Areg SDK is worth your time.

Areg SDK is a C++ service framework that automates threading, inter-process communication, service discovery, fault recovery, and message dispatch — across thread boundaries, process boundaries, and network boundaries — using a single consistent programming model.

The same service code runs:

• Multithreaded (components in the same process)
• Multiprocessing (components on the same machine)
• Multi-device (components across a network)

No code changes. Configuration only.

Areg SDK implements Object RPC (ORPC) — a service model where components expose typed interfaces and communicate through generated proxies, regardless of where they run. Unlike gRPC or ZeroMQ, the same proxy code calls a thread, a process, or a networked device — the framework resolves the location at runtime with no API changes.

┌─────────────────────────────────────────────────────────┐
│  Same code. Same interface. Different deployment.       │
│                                                         │
│  Thread A ──────────────── Thread B      (in-process)   │
│  Process A ─── mtrouter ── Process B     (same machine) │
│  Device A  ─── mtrouter ── Device B      (network)      │
└─────────────────────────────────────────────────────────┘

Consumers reference services by name, not by network address or endpoint. The framework connects a consumer to the named service wherever it runs — whether in the same process, on the same machine, or on a remote node.

What the framework handles automatically:

• Thread lifecycle and synchronization
• Service discovery and registration
• Request and response routing and dispatching
• Fault detection and watchdog restart
• Connection management and reconnection

What you write:

• A service interface definition (.siml file) — designed visually with Lusan or edited as XML
• Extend generated provider and consumer classes with business logic

The code generator produces all RPC infrastructure — serialization, proxies, events, and service provider and consumer base classes. You fill in the logic.

A service interface defines the API contract: data types, attributes (pub/sub), requests, responses, broadcasts, and constants. A service is a named component instance that implements one or more interfaces. Consumers declare which named service they depend on — the framework connects them automatically when that service becomes available anywhere on the network.

The workflow from interface definition to running code:

MyService.siml  ──►  codegen.jar  ──►  MyServiceProviderBase.hpp
  (design in Lusan)        │           MyServiceConsumerBase.hpp
                           │           MyServiceProxy.hpp
                           │           Serialization code
                           |           Event objects

CMake integration — one line generates and links all infrastructure:

addServiceInterface(MyServiceLib ./services/MyService.siml)

For full details, see the Service Interface Guide.

Areg SDK's transport layer is designed for production-grade data pipelines. The numbers below are measured on mobile-class consumer hardware and include data serialization, event dispatching, and multithreading — not raw socket throughput.

🔹 Key Differentiators:

• Complete automation — Not just transport, but threading, dispatch, and lifecycle
• True location transparency — Same interface whether thread, process, or network
• Service Discovery — automatically connects service consumers and providers by name, and routes messages
• Integrated stack — Framework + Router + Tools + Logging in one cohesive SDK
• High-throughput transport — Full service stack, not stripped-down benchmark conditions

git clone https://github.com/aregtech/areg-sdk.git
cd areg-sdk
cmake -B build
cmake --build build -j20

Example location after build:

# Linux
./product/build/gnu-g++/linux-64-x86_64-release-shared/bin/01_minimalrpc.elf

# macOS
./product/build/llvm-clang++/macos-64-arm64-release-shared/bin/01_minimalrpc.mac

# Windows
.\product\build\msvc-cl\windows-64-amd64-release-shared\bin\01_minimalrpc.exe

What happens: The developer defines a model — a structured declaration of threads, components, and their provided or consumed services. A single call to Application::load_model() instantiates all threads, loads components, and starts services automatically. No manual thread creation or object management required.

At runtime, the service consumer detects the provider, sends a hello request, the provider prints 'Hello Service!' and triggers an application-quit event. Application::unload_model() then stops all services, exits threads, and notifies every consumer that services are no longer available — all handled by the framework.

Models can be defined statically at compile time or constructed dynamically at runtime. Loading and unloading is always dynamic and safe.

Expected output:

'Hello Service!'

The companion example 02_minimalipc runs the same ServiceComponent and ClientComponent code in separate processes via mtrouter. Change only areg.init to point mtrouter at a remote machine and it becomes device-to-device communication. These two examples are the concrete proof of "same code — thread, process, network."

git clone https://github.com/aregtech/areg-sdk.git
cd areg-sdk
cmake -B build -DAREG_BUILD_EXAMPLES=OFF
cmake --build build -j20

Then use the project setup tool:

# Linux / macOS
./areg-sdk/tools/setup-project.sh

# Windows
.\areg-sdk\tools\setup-project.bat

After generation, build with:

cd <your_project>
cmake -B build
cmake --build build -j20

1. 01_minimalrpc — Multithreading: service provider and consumer in separate threads, one process, no mtrouter
2. 02_minimalipc — IPC: the same components from 01_minimalrpc running in separate processes via mtrouter
3. 03_helloservice — Extended progression: three projects showing the same service and consumer in one thread → separate threads → separate processes
4. 16_pubmesh — Service mesh: multiple local and public services discovering each other automatically
5. 23_pubdatarate — Platform-dependent high-throughput benchmark: 2.2–7 GB/s and 1M+ msg/s on localhost
6. More Examples — Advanced patterns and features

Areg SDK uses an Object RPC (ORPC) model. Services expose typed interfaces; consumers communicate through generated proxies. The framework routes all communication — whether the target is a thread, a process, or a remote device.

┌──────────────────────────────────────────────────────────────────┐
│  Service Interface (.siml)                                       │
│       │                                                          │
│       ├─ Code Generator ──► Provider Base  (implement logic)     │
│       │                     Consumer Proxy (call methods)        │
│       │                                                          │
│       └─ Framework ────────► Service Registry                    │
│                              Thread Manager                      │
│                              Message Dispatcher                  │
│                              Watchdog                            │
└──────────────────────────────────────────────────────────────────┘

A service interface is the API contract — data types, requests, responses, broadcasts, and constants defined in a .siml file. A service is a named component instance that implements one or more interfaces. The same interface can be implemented by many services playing different roles.

A consumer claims a specific service by name — "I need HP-Lab1." The framework connects them when that named service becomes available anywhere on the network, and notifies the consumer immediately. No polling. No manual connection management.

The same service operates identically at three deployment levels:

Components can be developed and tested in a single process, then deployed across machines with only configuration and build script changes.

Areg SDK is designed for controlled private networks — deployments where nodes are known, the network is trusted, and communication patterns are defined at design time.

Mist layer — Device clusters: sensors, actuators, and controllers form a local service mesh, resolving each other by name automatically without a central broker.

Edge layer — Gateway nodes: aggregate data from mist clusters, run local inference or control logic, and expose services to private infrastructure.

Private infrastructure — Servers and workstations: process edge data, coordinate distributed workloads, and host operator tools.

The same service interfaces, generated code, and operational model work at every layer — a vertically consistent architecture from device cluster to data center.

The answer to "why Areg SDK and not something else" is different for each domain, but the underlying reason is always the same: Areg SDK combines high-throughput transport, automated threading, location-transparent services, and built-in fault recovery in a single cohesive stack — with only configuration changes required when moving between thread, process, and network deployment.

📖 For more use cases, diagrams, and patterns, see USECASES.md.

Why Areg SDK: Imaging pipelines — laser microscopy, X-ray, electron microscopy, machine vision — move continuous multi-megabyte frames between acquisition, processing, and storage processes. At 2.0–6.0 GB/s full-stack IPC on a standard laptop CPU, Areg SDK covers the software transport layer for virtually every such pipeline without custom networking code or stripped-down benchmarks. Few service-oriented C++ frameworks reach this throughput with full service semantics active.

What this means in practice: Replace custom shared-memory hacks and platform-specific IPC with typed, named service interfaces. Pipeline stages can be rearranged from threads to separate processes to separate machines with only configuration and build script changes.

Why Areg SDK: An edge AI pipeline — sensor acquisition → preprocessing → model inference → output / telemetry — requires fast IPC between stages that may run as threads, processes, or distributed nodes depending on hardware constraints. Areg SDK's location transparency means the pipeline topology can change without touching the inference or acquisition code. Few frameworks combine this flexibility with IPC throughput rates that match hardware DMA and PCIe data rates on standard CPUs.

What this means in practice: Develop and test the full pipeline in a single process. Deploy acquisition on a dedicated core process and inference on a GPU-attached process. Scale to distributed nodes. Only configuration and build script changes at each transition.

Why Areg SDK: Kernel-mode driver development is months of specialized work, requires OS-specific expertise, and produces code that is dangerous to debug and expensive to maintain. Areg SDK enables a driverless architecture: the device application exposes its functionality as a named service. Any host application calls the device API through a generated proxy — no driver installation, no kernel-mode code, no special permissions.

What this means in practice: External hardware (measurement instruments, industrial sensors, embedded controllers) registers as a named service via mtrouter. Host applications connect to that specific device by name — exactly as they would connect to any local service. Development time drops from months to days. The device is debuggable, testable, and upgradeable like any user-mode application.

Why Areg SDK: Industrial control systems fail in ways that are hard to predict and expensive to recover from manually. Areg SDK's built-in watchdog restart, automatic service re-registration, and fault-tolerant reconnection handle the failure cases that break hand-written IPC code. Components restart their threads and reconnect without operator intervention — and without changing a line of application logic.

What this means in practice: Sensor fusion nodes, PLC replacement controllers, and robot arm coordinators communicate through typed service interfaces. When a node's thread restarts after a fault, it re-registers and consumers reconnect automatically. No supervisory restart scripts, no manual reconnection logic.

Why Areg SDK: A digital twin requires bidirectional real-time synchronization between a physical device and its software representation. Areg SDK's event-driven architecture delivers state changes from hardware to software and commands from software to hardware with no additional middleware layers. The same service interface defines both the physical device and its digital twin — providing an identical API whether connecting to real hardware or its virtual counterpart.

What this means in practice: Replace polling loops and custom TCP protocols with pub/sub attribute broadcasting and request/reply RPC. The digital twin can mirror, simulate, or proxy the real device — all sharing the same service interface. Consumers require no code changes when switching between real hardware and its twin.

Why Areg SDK: Testing against real hardware is slow, expensive, and unavailable during early development. Because Areg SDK services are discovered by name, a simulated service registered under the same name is indistinguishable from the real hardware service. Swap the real hardware service for a simulation that registers under the same service name — the rest of the application never notices the difference. No test-specific code paths, no mocking frameworks, no conditional compilation.

What this means in practice: Develop and verify full application business logic before hardware exists. Run automated regression tests against simulated services in CI. Deploy to real hardware with zero application code changes.

Why Areg SDK: C++ backend systems — game servers, simulation engines, financial data processors, real-time analytics — typically build custom threading and IPC from scratch. Areg SDK replaces that infrastructure with a generated, typed service layer that handles thread safety, message dispatch, and inter-process routing automatically. With stable consumer dispatch at 300–600K msg/s on a single machine (platform-dependent), the framework does not constrain throughput for any realistic backend workload.

What this means in practice: Define service interfaces, generate the infrastructure, implement the logic. Services scale from in-process components to distributed nodes without architectural changes. The same watchdog and logging infrastructure that works in embedded deployments works in backend deployments.

In progress (2026):

• RTOS platform support (FreeRTOS, Zephyr)
• Enhanced serialization throughput (targeting 500K+ stable msg/s consumer dispatch)
• Python-based code generator (replaces Java dependency)
• Shared memory transport (zero-copy for same-machine IPC)
• Secure communication (optional TLS for mtrouter connections)
• Extended networking protocols

Considering for community input:

• Language bindings (Python, Rust)
• Cloud-native deployment patterns
• WebSocket transport

The wiki covers all deployment, integration, and development scenarios in depth:

• Installation and Build - Cross-platform builds, toolchains, CMake integration
• Build Options and Integrations - FetchContent, packaging, embedding
• Networking and Communication - Router setup, IPC, low-latency messaging
• Logging and Monitoring - Distributed logging for debugging
• Persistence - Local data storage
• Development and Testing Tools - Code generator, Lusan, testing utilities
• Troubleshooting - Common issues and solutions
• Examples and Tests - Sample projects catalog
• HOWTO Guide - Practical development tasks

Areg SDK is released under the Apache License 2.0 — a permissive license suitable for both open-source and commercial use.

Commercial support: Enterprise licensing, training, and dedicated support available. Visit areg.tech or email info[at]areg[dot]tech.

Add this badge to your project if you use Areg SDK.

Contribute:

• Issues
• Discussions
• Contributing Guide
• Wiki

Showcase your project: If you build something with Areg SDK, open a discussion and tell us about it.

Areg (Արեգ) — Old Armenian: the Sun.