ts_netstack_smoltcp_core (netcore)
Command-channel-driven userspace network stack.
This is an opinionated wrapper around [smoltcp] that provides an easier-to-integrate,
more-portable API.
Organization
This is the core crate, which just provides a [Netstack] type that contains the
required state and logic to drive the contained [smoltcp::iface::Interface] to process
commands received over a [Channel]. The ergonomic sockets API around the
remote end of that channel is provided by ts_netstack_smoltcp_socket.
The whole thing is integrated along with runtime functionality in ts_netstack_smoltcp.
Motivation
-
Usage of
smoltcpsockets requires access to their backing [SocketSet][smoltcp::iface::SocketSet] (buffer storage). This functionally attaches them to the lifetime of that storage, meaning that synchronous access across threads would require passing aroundArc<Mutex<SocketSet>>and grabbing locks everywhere that's used. Instead, this crate uses a channel-oriented approach, converting the socket function call API into a set of RPC-style request/response messages. -
Lack of direct integration with
async: the command-channel paradigm means that this is straightforward in our implementation: a task or thread drives the netstack, and sockets enjoy asynchronous semantics by polling on channel sends and receives. Because the channel library we're using ([flume]) supports both sync and async operation, this means that sockets work naturally in sync contexts as well. -
Lack of features:
smoltcpis a minimal core crate -- it doesn't provide TCP accept logic, any commitments re: allocation, a complete polling loop, garbage collection of closed TCP connections, or a way to block until e.g. a TCP connection is established.
Example
extern crate ts_netstack_smoltcp_core as netcore;
use SocketAddr;
use Bytes;
use Instant;
use Medium;
use ;
Compare the examples in ts_netstack_smoltcp_socket and ts_netstack_smoltcp (which
do the same thing as this example) for an indication of the abstraction that crate
provides.