Skip to content

Network abstractions crate #348

Closed
Closed

Description

@benjaminjt

Would there be some value in a crate for network layer abstractions (e.g. Ethernet, IP, TCP, etc.) in the same vein as embedded-hal?

This may a naive view, but it seems to me that it would be very useful for building up an embedded networking stack. For example:

A common Ethernet trait implemented by board support and driver crates would allow TCP crates (such as smoltcp) to run on arbitrary hardware.

A common TcpSocket trait implemented by TCP crates (and maybe even std?) would allow higher level abstractions (such as TLS or HTTP) to be built more easily.

Activity

  1. ryankurte commented on May 3, 2019

    @ryankurte
    Contributor

    hey interesting idea! seems possible, though i suspect we'd need some more examples to extract the commonality and create something generally useful. my suggestion would be that it might be worth developing the networking bits outside the wg with the goal of adoption once it's demonstrated / useful?

    also i think an ethernet peripheral trait (if it can be generalised) is definitely in scope for embedded-hal ^_^

  2. michalfita commented on Jul 10, 2019

    @michalfita

    Don't forget you need Ethernet at two levels of abstraction, original IEEE 802.3 which can be directly under IP protocol and works today on copper or fibre cable and higher one for everything that mimics Ethernet frames on top of medium like IEEE 802.11 or FrameRelay. The former fits into embedded-hal as would address implementation over physical peripheral of the MCU, but then the latter shall be part of network abstractions. Maybe the one from embedded-hal could directly act as implementation for the one from network abstraction crate (if that would be the case)?

  3. thejpster commented on Sep 12, 2019

    @thejpster
    Contributor
  4. burrbull commented on Sep 12, 2019

    @burrbull
    Member

    You can look also here:
    https://github.com/japaric/jnet

  5. newAM commented on Jun 7, 2020

    @newAM
    Member

    Would there be interest in just embedded networking types to start with? It would not solve the problem; but it would improve portability across existing embedded networking libraries.

    Specifically I am thinking there should be types for ipv4/ipv6 addresses and EUI-48/EUI-64 hardware addresses. These have very well defined standards, and in the case of IP address there is a lot to leverage from ip.rs in std::net.

  6. jonas-schievink commented on Jun 7, 2020

    @jonas-schievink
    Contributor
  7. ryankurte commented on Jun 7, 2020

    @ryankurte
    Contributor

    ahh glad to see some progress on the move of types to core! supporting both std and no_std at this time is a right pita without em.

  8. ryan-summers commented on Jun 8, 2020

    @ryan-summers

    This is another crate that I've seen used in a few embedded crates: https://github.com/thejpster/embedded-nal

    Edit: Just now noticing the original author is in this thread 😄

  9. eldruin commented on Oct 6, 2020

    @eldruin
    Member

    We agreed in today's WG meeting that embedded-nal is the place for these abstractions.
    Further ideas and improvements are welcome over there!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions