batonius
commented
6 years ago Now the layers themselves, the main difference between the LinkLayer and RoutingLayer traits is the IfaceId argument used in the former to identify the interface a packet has been received from or should be transmitted to. The Network Layer knows nothing about the interfaces, their IPs, neighbors, routes, etc. and uses the abstraction provided by a RoutingLayer, but receives a reference to IfaceCapabilites struct with each packet to see if checksum validation is necessary. Neighbour discovery, ARP tables, are implemented at the Link Layer since the specifics depend on the technology.
The specifics of the traits is the key point of the solution and I'm far from being happy with them, but right now I see them roughly as
enum RouteError<E> {
CantRoute,
Other(E),
}
enum LinkError<E> {
CantLink,
Other(E),
}
enum Action<'a> {
None,
Arp(ArpRepr),
Icmpv4((Ipv4Repr, Icmpv4Repr<'a>)),
Icmpv6((Ipv6Repr, Icmpv6Repr<'a>)),
Raw((IpRepr, &'a [u8])),
Udp((IpRepr, UdpRepr<'a>)),
Tcp((IpRepr, TcpRepr<'a>))
}
trait RouteLayer {
fn poll<'a, F, E>(&mut self, f: F) -> Result<usize, RouteError<E>>
where F: Fn(&IfaceCaps, &'a IpPacket, &'a [u8]) -> Result<Action<'a>, E>;
fn emit<F, R, E>(&mut self, &IpRepr, f: F) -> Result<R, RouteError<E>>
where F: Fn(&IfaceCaps, &mut [u8]) -> Result<R, E>;
}
trait LinkLayer {
fn poll<'a, F, E>(&mut self, f: F) -> Result<usize, LinkError<E>>
where F: Fn(IfaceId, &IfaceCaps, &'a IpPacket, &'a [u8]) -> Result<Action<'a>, E>;
fn emit<F, R, E>(&mut self, IfaceId, &IpRepr, f: F) -> Result<R, LinkError<E>>
where F: Fn(&IfaceCaps, &mut [u8]) -> Result<R, E>;
}
whitequark
fintelia
I've been thinking about #55 for a while and I've come up with a much broader plan which would require significant refactoring, so I'm posting my not-so-concrete-yet thoughts here to get some early feedback.
The basic idea is pretty obvious - to split up the
EthernetInterfacemonstrosity into components representing layers in the classical network scheme, specifically the Network (aka IP) Layer, and the Link Layer, to which I would add the third, intermediate layer - the Routing Layer. The next logical step is to express these layers as traits and split the stack into independent composable modules, making each implementation of a layer generic over the specific implementation of the underlying layer, something likeEthernetInterfacecan be parametrized withDevicenow. It also would be possible to create middleware layers which consume an instance of a layer and implement the same layer on top of it with additional features.Now, one of the problems with
smoltcpas a project IMO is the inherently conflicting requirements the users have - coming from Redox, I'm all for usingstdandalloceverywhere to get more advanced features like routing and multiple interfaces, something the embedded users understandably want to be able to avoid. With the proposed organization,smoltcpbecomes not so much a fits-all network stack, but a set of components which could be easily put together to create a network stack with the desired set of features, with some components unapologetically relying onstdandalloc, while the others beingno_std. Since the concrete organization of the stack will be known at the compile time, all the calls to the intermediate layers will be inlined and no dynamic dispatch will be used implicitly.The current stack would be equivalent to
NL -> Default Gateway RL -> Ethernet LL -> Device, the simplest would beNL -> Loopback LL(since there's nothing preventing a type from implementing bothNetworkLayerandRoutingLayertraits), and Redox would use something likeNL -> IP Fragmentation RL -> Looback RL -> Table Routing RL-> Multiplexing LL, the latter using dynamic dispatch toLinkLayerto operate on a set ofEthernet LL,PPP LL,802.11 LL, etc. Alternatively, the multiplexing could be fixed with the predefined set of Link Layers: