API Reference¶
Nalix API documentation is organized by package boundary and runtime responsibility so you can move from contracts (Nalix.Abstractions) to execution (Nalix.Runtime, Nalix.Network) and then to client transport (Nalix.SDK) without mixing concerns.
Where to start¶
If you're looking for the core interfaces and classes that drive Nalix:
- Packet contracts & attributes → Common API
- Handlers, routing & metadata → Runtime Routing
- Middleware pipelines → Runtime Middleware
- TCP/UDP transport & protocols → Network API
- Client sessions & requests → SDK API
Important
Most users should NOT start by reading the API reference.
If you are new, follow the Recommended Path
or explore the Guides first.
Source Mapping¶
src/Nalix.Abstractionssrc/Nalix.Frameworksrc/Nalix.Runtimesrc/Nalix.Networksrc/Nalix.Hostingsrc/Nalix.Runtimesrc/Nalix.SDK
Why This Structure Exists¶
Nalix is split into focused packages with explicit layering:
Nalix.Abstractionsdefines shared contracts and attributes.Nalix.Frameworkprovides reusable framework primitives (packet model, configuration, memory, security, tasking).Nalix.Runtimeturns packets into handler execution.Nalix.Networkowns listeners, connections, protocols, and session stores.Nalix.Hostingadds host/builder composition on top of runtime + network.Nalix.Runtimeexposes reusable middleware and throttling components.Nalix.SDKprovides client-side transport sessions and extension APIs.
This keeps server runtime internals, transport lifecycle, and client APIs independently evolvable.
Package Responsibility Matrix¶
| Package | Primary responsibility | Use when | Avoid when |
|---|---|---|---|
Nalix.Abstractions |
Core interfaces/enums/attributes | You need shared contracts across packages | You need concrete runtime behavior |
Nalix.Framework |
Core framework implementations and infrastructure | You need packet registry, serialization, memory/security utilities | You only need transport/session lifecycle |
Nalix.Runtime |
Packet dispatch and middleware execution | You are building handler execution pipelines | You only need socket listener primitives |
Nalix.Network |
Connection + listener + protocol runtime | You are implementing server transport/runtime loops | You only need pure client transport |
Nalix.Hosting |
Host-style startup composition | You want builder-driven server bootstrapping | You prefer manual wiring |
Nalix.Runtime |
Reusable inbound middleware and limiters | You need throttling/middleware components standalone | You need complete server hosting surface |
Nalix.SDK |
Client transport sessions and request/response helpers | You build Nalix clients | You implement server listeners |
Progressive API Path¶
- Start with Common contracts and connection/session abstractions.
- Learn packet runtime flow in Runtime API.
- Move to transport lifecycle in Network API.
- For clients, continue with SDK API.
- For production startup composition, use Hosting API.
Suggested Architecture Diagrams¶
- Dispatch sequence:
IBufferLease -> IPacketRegistry -> PacketContext<TPacket> / IPacketContext<TPacket> -> handler. - Server layering: Listener (
Nalix.Network) above runtime dispatch (Nalix.Runtime) and shared contracts (Nalix.Abstractions). - Client-server handshake lifecycle using
Nalix.SDK.Transport.Extensions+ runtime handlers.