Feature > Echo Handle

[olsky]

Would it be of interest for the framework?

What I'm after:

• to have a dedicated handle, to echo the received packet
• echo function would replace the mac with the sender's one
• propagate an event to application. application logic would then decide what to do with it

What is it good for:

• node could use it for the discovery of nearby nodes
• could be used for time sync
• could be used to measure propagation time

Adding a configuration for the handle to enable echo of received packet, which will use an alternative access address to send it.

A retransmit should be disabled for this Handle, in order to send it only back to the transmitter, which will check the version and CRC of original packet and refuse other packets.

Does it sound reasonable?

[trond-snekvik]

This sounds interesting. Do you want to keep it single hop, to discover all your neighbors, or to ping devices across the network, with TTL-fields and timestamps? Do you imagine it as a broadcast type message, where all devices respond to the "request", or like a targeted message to a specific device?

[olsky]

Your questions hinting to more genering, global solution. :+1:

I was experimenting with the first-ring neighbors. So the payload was filled with timestamp and mac-address to propagate time and check the time-spent in transition from node-to-node.

Answering your questions: single hop and target a specific device. This will limit memory usage, I think, as to keep routing tables on each device is expensive.

Another benefit is timestamp / current time propagation, each hop adds its delta.

[trond-snekvik]

This feature would complement the time-sync functionality really well.

I believe this can be solved without routing tables, but as with all unicast-traffic in a flood-based network, it's a bit of a waste of bandwidth.

I think this can be added to the pile of things pushing for addressability/a message based mesh, versus the handle system we have today. We're seeing several users creating addressing schemes/message-based communication on top of the current mesh, forcing it to behave like traditional communication networks, instead of the state-sync nature of the OpenMesh. This feature-suggestion also highlights some of the shortcomings of the current system:

• For addressing individual devices for pinging, the current system has a gap to fill. While using the advertisement address of each device as the address of a ping message would work, getting a list of all advertisement addresses in the mesh, and keeping it up to date as devices are added to/removed from the mesh (so that we'd know who we should ping) is a big task in itself. The address-length is excessive and the addresses themselves are (pseudo-) random.
• The version-system doesn't allow TTL-fields in the packet payload. The packet must either stay the same across all hops, or get a new version number per hop. The first keeps us from counting hops, and the latter can easily lead to conflicts and state problems.

Ideally, the mesh should be versatile enough to allow this (and similar functionality) to be implemented in the application, without any special treatment in the framework, but this is not the case today.

Do you have any opinions on this, @olsky?

[olsky]

Thank you @trond-snekvik , I agree and support your thoughts.

Personally, the state-sync nature of the Mesh is very flexible. And I dont see addressing as a gap: it is quite easy to implement to, and it is a metter of payload size.

... it brings me back to another feature-request I wanted to post: configurable payload size (easily configurable S1 S0 e tc) :-)

Also, I do not think the TTL will bring benefit to the OpenMesh, with versions and trickle -- we have all we need.

On the echo functionality itself, here you are bringing me back on the path when you say "the mesh should be versatile"... the echo is simple to implement (having peek-feature introduced in latest release), what we would probably need is the priority field in the fifo events and possibility to insert high-prio events on top of the queue, so that package will be sent immediately. But we need to expose the fifo-event-queue to the application...

Fifo-queue in app is two-fold solution:

• problematic is messed with
• but as a feature if used with care: think of sending a custom adv packet like eddystone/iBeacon ;-)

On Ping-node: in my experiments, each node is sending an info packet every X seconds, which is used to have the map of live-nodes. I think it should be left to application, then OpenMash could remain THE framework which supports meshing and the application is up to: take broadcasting or routing mode ;-) if I got you right...

[trond-snekvik]

I believe you're right about the one-hop echo, this should be fairly easy to implement with the current mesh, and could also be made a native feature. Creating a similar solution for multihop is also possible, but the state-system does not provide a lot of freedom to do things like hop distance, path discovery or routing.

The FIFOs: Are you envisioning some "send now" type functionality, where you can trigger the radio immediately? I can agree that it's useful, but like you're saying, it's a dangerous feature to add. We've been considering adding app-controlled advertisers to the framework, which would allow the application to run their own advertisements in timeslots, but the Softdevice already provides this functionality, and duplicating functionality might cause some confusion. Adding shortcuts to the radio-queue will be even more powerful, but we're a bit cautious to put this power in the main API. With no modification to the framework, you could actually be doing this already, with the tc_tx function.

[olsky]

I would opt for the echo as a native feature, it could be surrounded with #ifdef macros to enable it easy or disable if not required.

On FIFOs: yes, a "send now" would be much appreciated (it could also land in an extra #ifdef for advanced users). I'm already "hacking" with this, and it would be nice to have it as the native feature, i would save some merge efforts :)

And +1 for the app-controlled advertiser :-) it is just in the same domain: adv-based mesh and thus adv-features are native.

In itself the FIFO in the OpenMesh is very powerful tool: it is there and it works, the temptation to use it for other features... is huge :-D

[trond-snekvik]

I'll see if I can find a fitting solution for echo, and take a look at "send now". Out of the two, I think echo is the most useful, the "send now" strikes me as something that can easily be abused or misunderstood.

Feel free to use the FIFO in other (nRF related :wink:) projects! I use it in other projects every chance I get.