Catherine
Catherine
I don't think FnOnce works in this signature. It's really unclear to me how this is supposed to work lifetime-wise too...
> Why not? The function would only handle a single packet per call (like it does today), so it would only invoke the closure once. How so? Right now poll()...
Good catch! I seem to have overlooked that while adding these functions. It is possible to use `PacketBuffer::dequeue_with` to return an error in this case (probably `Error::Truncated`). What we *should*...
Thanks, will fix!
> It seems when I write a straightforward case (do a bunch of `send!` calls with frames but one missing from the sequence), the `recv!` call at the end --...
@jhwgh1968 You can't call `s.rx_buffer.dequeue*` if you want to continue using the socket afterwards. Take a look at the implementation of `TcpSocket::recv`; you're skipping `TcpSocket::recv_impl`, which means `s.remote_seq_no` doesn't get...
Great to hear, and thanks for your work and patience!
> Sockets can be bound to a specific IP address. As a result, a solution should support several sockets of the same type listening on the same port but bound...
Regarding ingress, using BTreeMap instead of a HashMap reduces the `std` requirement to a mere `collections` requirement, and makes it possible to do fast ingress handling on no_std code. Otherwise...
OK, this looks more or less fine to me. A few suggestions: * Let's keep `SocketSet` and what you call `LookupTables` separate. Right now, with the `BTreeSet`, there is a...