L3 - Transport layer

The Layer 3 (Transport Layer) elevates the stack's focus from simply moving bytes between devices to managing application-level connections and delivery policies. While Layer 2 ensures that data reaches the correct physical machine within strict MTU limits, Layer 3 is responsible for port-level routing, ensuring the payload reaches the exact process or code block meant to handle it. It is at this layer that developers choose the reliability paradigm that best fits their data: guaranteed, ordered delivery for critical state changes, or lightweight, unacknowledged streams for high-frequency sensor telemetry.

Overview

Crucially, unlike Layer 2 with its universal 5-byte routing header, Layer 3 does not enforce a single, monolithic packet structure. Instead, the layout of an L3 payload (referred to within the NSLP stack as a "frame" - a deliberate, if slightly quirky, nod to traditional OSI model nomenclature) is entirely dictated by the specific transport protocol being used.

Official Transport Protocols

Just as Layer 1 adapts to the physical medium, Layer 3 adapts to developer's specific delivery requirements. Depending on whether you route your data through the connection-oriented SL-TCP or the fire-and-forget SL-UDP, the L3 frame will dynamically adapt its header footprint to include only the necessary fields. This flexibility ensures that your application only pays the overhead bandwidth cost for the network features it actually uses.

SL-TCP

SL-TCP (ServiceLink Transmission Control Protocol) is designed for mission-critical payloads where guaranteed, ordered delivery is non-negotiable (e.g., configuration changes, state commands). Operating as a lightweight, stateful protocol, it ensures absolute data certainty through a strict Stop-and-Wait mechanism. Because it must guarantee that no data is lost or processed out of order, the SL-TCP frame carries a slightly heavier header to accommodate explicit acknowledgment tracking.

SL-UDP

SL-UDP (ServiceLink User Datagram Protocol) is the lightweight, high-speed alternative built for low-latency communication. It strips away the complex states and delivery guarantees of TCP, acting as a true "fire-and-forget" protocol. By omitting acknowledgment tracking and retry logic, SL-UDP significantly reduces its header footprint. This makes it the ideal choice for high-frequency data streams (such as real-time sensor telemetry or periodic heartbeat broadcasts) where getting the newest data immediately is much more important than recovering an older, dropped frame.