Egor

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...

@whitequark It would be nice to be able to use `std`-depended crates for some fancy data structures, for example, something `managed` won't support. Then again, with the proposed scheme, there's...

The first attempt: https://github.com/m-labs/smoltcp/compare/master...batonius:layers , I've decided against separate traits for routing and link layers. Currently, the trait looks like ```rust pub struct IfaceDescr, pub id: IfaceId, } pub struct...

> what with the many ManagedSlice::Owned instances in your PoC code. Well, that's PoC after all, I'm going to rewrite the `Loopback` layer using `RingBuffer` once I'm happy with the...

Then I'll try to rethink the design to keep it this way, maybe along the lines of the old `Device` trait, with handler types owning packet buffers and returning them...

I'm back, sorry for disappearing for so long. The last couple of weeks I've been playing with the splitting approach to the issue, mostly trying to resolve the lifetime issues....

> This already works, doesn't it? Yeah, I meant it for the packet dispatch mechanism, meaning a simple port -> socket map won't work. > I have an idea that...

I don't like the idea of using `routing` in the names for packet dispatch. "Routing" is a well-defined concept and packet dispatch isn't usually a part of it. For starters,...

> Nope! We can use BTreeMap::range to perform just one search. I don't get it. Suppose you have three sockets, *:123, 192.168.1.1:123 and 192.168.1.3:123. They are stored in the BTreeMap...

So here's my current attempt: https://github.com/m-labs/smoltcp/compare/master...batonius:packet_dispatch . I've spent some time on these lifetimes :) What I'm thinking of doing next is 1. Add `process_repr` methods to all the sockets...