nihalpasham commented on Aug 31 •

Indeed, this a great starting point. I guess, the next step is how do we layer ockam on top of such an example? Do we have any examples for porting ockam onto a different transport layer?

mrinalwadhwa commented on Aug 31 •

We'll need to write a new transport crate - maybe we call it ockam_transport_tcp_smoltcp

ockam_transport_tcp is a good reference for a transport implementation.

All the crates are here, ockam_transport_websocket is a good reference too.

Okay, I finally managed to get down to cloning the repo, today. I'm still trying to wrap my head around a couple of things, so I could be wrong here but here's what I've gathered.

To build the ockam-transport-smoltcp impl while retaining the existing api (more or less), we'll need 3 things

• no_std ockam-node impl:
  • guess, we have a barebones impl for this i.e. a global executor to poll and execute futures.
  • For the absolute simplest impl, I guess we can simply collect all futures into a single async block and pass them to the executor.
  • And then use another (maybe interrupt driven) mechanism to register with a waker for notifications.
• high-level ockam-transport layer wrapper:
  • This layer just spawns 3 ockam-workers - TCPRouter, TcpSendWorker, TcpRecvProcessor
  • I presume this layer doesn’t need to change much i.e. we'll just need new names for the types (maybe)
  • Question here - what are inlets and portals actually used for i.e. are they required to establish TCP connections (i.e. connect, listen, send, receive)?
• replace tokio async-wrappers used to instantiate tcpsockets/streams with a smoltcp abstraction:
  • the high-level ockam-transport layer calls into tokio to get a TCPstream and send/receive data.
  • we'll need a similar api around smoltcp

Does this make sense i.e. is my understanding correct or am I missing something?

Quick note on testing during development: smoltcp can run in a no_std desktop environment as a user-space application, we can probably use this example (which uses TapInterfaces) to start-with, before we move to an actual embedded-device (to make it easier).

nihalpasham commented on Sep 6 •

another question: for ockam-no-std nodes, is there a plan to build on the existing ockam_node_no_std impl which uses the executor crate or is that just a placeholder. The reason I ask is because executor uses heap allocation and dynamic dispatch (via the alloc dependency) - both of which may not be available in embedded environments.

antoinevg commented on Sep 6

• no_std ockam-node impl:
  • guess, we have a barebones impl for this i.e. a global executor to poll and execute futures.
  • For the absolute simplest impl, I guess we can simply collect all futures into a single async block and pass them to the executor.
  • And then use another (maybe interrupt driven) mechanism to register with a waker for notifications.

I'm busy putting the finishing touches on the Ockam no_std port.

Basically it ends up looking something like this:

You can follow the PR progress here: #1831

There's also a second PR in progress which drops the requirement for scheduling blocking functions in environments without pre-emptive multitasking: #1832

Please ask away if you run into any issues trying these out, I'm still polishing some of the rougher edges.

is there a plan to build on the existing ockam_node_no_std impl which uses the executor crate or is that just a placeholder. The reason I ask is because executor uses heap allocation and dynamic dispatch (via the alloc dependency) - both of which may not be available in embedded environments.

executor was just a placeholder.

For embedded targets we're currently using our own executor which supports most no_std + alloc configurations.

Once we have more data on how Ockam performs on embedded hardware we'll be in a good place to tackle a pure no_std environment for zero-alloc targets next.

• high-level ockam-transport layer wrapper:
  • This layer just spawns 3 ockam-workers - TCPRouter, TcpSendWorker, TcpRecvProcessor
  • I presume this layer doesn’t need to change much i.e. we'll just need new names for the types (maybe)
  • Question here - what are inlets and portals actually used for i.e. are they required to establish TCP connections (i.e. connect, listen, send, receive)?

Paging @SanjoDeundiak

• replace tokio async-wrappers used to instantiate tcpsockets/streams with a smoltcp abstraction:
  - the high-level ockam-transport layer calls into tokio to get a TCPstream and send/receive data.
  - we'll need a similar api around smoltcp

Worth a look:

https://crates.io/crates/embedded-nal

Does this make sense i.e. is my understanding correct or am I missing something?

Perfect sense, great questions, thank you! :-)

Quick note on testing during development: smoltcp can run in a no_std desktop environment as a user-space application, we can probably use this example (which uses TapInterfaces) to start-with, before we move to an actual embedded-device (to make it easier).

Nice!

SanjoDeundiak commented on Sep 9

Hey @nihalpasham ! Inlets and outlets are additional features, which we probably want to have in the future, but don't think about them for first implementation. They are not necessary to make basic connections/exchange messages.