Design Constraints: Aegis Packet Engine
This document outlines the strict guidelines governing all code contributions on the Aegis packet processing path.
1. Hot-Path / Fast-Path Constraints
The hot path includes all functions executed for each packet frame (parsing, dispatching, tracking, rule evaluation, metrics counting, writing).
- No Heap Allocations: Dynamic memory allocation (
malloc,free,new,delete,std::make_shared,std::make_unique) is prohibited. - No Mutexes: Mutex locks and standard blocking locks are banned. Synchronization must utilize atomic operators, SPSC queues, or thread-isolation patterns.
- No Virtual Functions: Virtual function calls and runtime polymorphism are banned to avoid vtable lookups and enable inline optimizations. Use templates or compile-time specialization.
- No
std::stringCopies: Do not construct or copy standard strings. Reference characters usingstd::string_view. - No RTTI: Run-Time Type Information (
dynamic_cast,typeid) is disabled. - No C++ Exceptions: Exceptions are prohibited on the packet loop. Use structured error codes or boolean return states. Keep functions marked
noexcept.
2. General Architecture Rules
- RAII (Resource Acquisition Is Initialization): All resource lifecycles (sockets, files, thread pools) are tied to scope.Destructors must coordinate cleanup.
- Rule of Zero: Prefers classes that do not declare custom copy/move constructors or destructors, letting the compiler generate them. Where custom resources are managed, implement the Rule of Five.
- Thread Ownership & Affinity: Thread lifetimes must be explicit. Pinning threads to CPU cores is standard behavior on supported systems (Linux), with safe preprocessor fallbacks.
- No Shared Mutable State: Worker threads operate on isolated connection tables and statistics counters to avoid cache invalidation between cores.
- Constexpr Usage: Define all configuration variables, protocol constants, and magic numbers as
constexprto resolve calculations at compile-time.