Module riot_coap_handler_demos::ping[][src]

Expand description

Placeholder for work-in-progress ideas

Only an idea so far; would take the mechanisms from sc_gnrc_icmpv6_echo, but overall use and evaluation would be quite different:

  • There’s a static list of potential pingings, quite possibly 1 long, whose state is queriable in /ping/[0-9a-f]{2} or similar. I did use a crate at some point which did quite this (where not necessarily all identifiers are active all the time; maybe it’s 2-long but still 256 possible identifiers, and all currently unused are 4.04)

    In a variation that uses heap allocation sparingly and fallibly, they could be truely heap allocated. (“You can ping 10 hosts at the same time, you just can’t run a traceroute concurrently”).

  • POST an address to what you want to ping, get a Location and a new pinging.

  • Ping responses are aggregated in the slot. No displaying the individual response, just min/avg/max time and sent/received counts. Duplicated counted best-effort maybe (replay window style, counting “regular”, “duplicate” and “came in so long after sending that I can’t tell any more”). At most storing the response source addresses (that would be useful in multicast pings), or error source addresses.

  • We’d need to run a thread somewhere that receives the GNRC events and also sends the messages. A single thread can serve all ongoing pings.

    A good design of the msg wrapper would allow this to run concurrently with any other message handling in an existing thread.

    If the thread interface is enhanced a bit (to allow eventually reaping threads), even the single thread’s stack could be heap-allocated. (It should manage to terminate on its own, but couldn’t free its own memory, that’s what the spawner or whoever owns the original memory allocation would need to do; given it’d be started from the CoAP thread, it’d probably hand it over to a reaper thread or somethe other PID-1-style task).