Crate smoltcp

source ·
Expand description

The smoltcp library is built in a layered structure, with the layers corresponding to the levels of API abstraction. Only the highest layers would be used by a typical application; however, the goal of smoltcp is not just to provide a simple interface for writing applications but also to be a toolbox of networking primitives, so every layer is fully exposed and documented.

When discussing networking stacks and layering, often the OSI model is invoked. smoltcp makes no effort to conform to the OSI model as it is not applicable to TCP/IP.

The socket layer

The socket layer APIs are provided in the module socket; currently, raw, ICMP, TCP, and UDP sockets are provided. The socket API provides the usual primitives, but necessarily differs in many from the Berkeley socket API, as the latter was not designed to be used without heap allocation.

The socket layer provides the buffering, packet construction and validation, and (for stateful sockets) the state machines, but it is interface-agnostic. An application must use sockets together with a network interface.

The interface layer

The interface layer APIs are provided in the module iface; currently, Ethernet interface is provided.

The interface layer handles the control messages, physical addressing and neighbor discovery. It routes packets to and from sockets.

The physical layer

The physical layer APIs are provided in the module phy; currently, raw socket and TAP interface are provided. In addition, two middleware interfaces are provided: the tracer device, which prints a human-readable representation of packets, and the fault injector device, which randomly introduces errors into the transmitted and received packet sequences.

The physical layer handles interaction with a platform-specific network device.

The wire layers

Unlike the higher layers, the wire layer APIs will not be used by a typical application. They however are the bedrock of smoltcp, and everything else is built on top of them.

The wire layer APIs are designed by the principle “make illegal states irrepresentable”. If a wire layer object can be constructed, then it can also be parsed from or emitted to a lower level.

The wire layer APIs also provide tcpdump-like pretty printing.

The representation layer

The representation layer APIs are provided in the module wire.

The representation layer exists to reduce the state space of raw packets. Raw packets may be nonsensical in a multitude of ways: invalid checksums, impossible combinations of flags, pointers to fields out of bounds, meaningless options… Representations shed all that, as well as any features not supported by smoltcp.

The packet layer

The packet layer APIs are also provided in the module wire.

The packet layer exists to provide a more structured way to work with packets than treating them as sequences of octets. It makes no judgement as to content of the packets, except where necessary to provide safe access to fields, and strives to implement every feature ever defined, to ensure that, when the representation layer is unable to make sense of a packet, it is still logged correctly and in full.

Packet and representation layer support

| Protocol | Packet | Representation | |–––––|––––|––––––––| | Ethernet | Yes | Yes | | ARP | Yes | Yes | | IPv4 | Yes | Yes | | ICMPv4 | Yes | Yes | | IGMPv1/2 | Yes | Yes | | IPv6 | Yes | Yes | | ICMPv6 | Yes | Yes | | TCP | Yes | Yes | | UDP | Yes | Yes |

Modules

Network interface logic.
Access to networking hardware.
Communication between endpoints.
Specialized containers.
Time structures.
Low-level packet access and construction.

Enums

The error type for the networking stack.

Type Definitions

The result type for the networking stack.