techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.6K
active users

#coap

0 posts0 participants0 posts today
Replied in thread

@chris_gammell You might want to join this year's @RIOT_OS summit: Rumor has it that there will be a presentation on the tools we use there to bridge the gaps between actual shell use (like, bidirectional character streams) and #CoAP based RPC.
(I didn't plan anything yet, but I do have an implementation of SSH-/mosh-like access to stdin/-out, so maybe I should file a talk too?)

Continued thread

As for multicast Block1 (block-wise PUT/POST request)… I think the block-size would have to be negotiated up front via a separate custom option.

Call it MCBlock1 (option 65000), unsigned integer consisting of:
- bits 0-3: SZX - Size exponent
- bit 4: P - Proposal
- bit 5: S - Master selection
- bit 6: C - Master cancellation

When a node wishes to send a blockwise file to a multicast group (via PUT or POST request payload) steps would be:

1. it sends a payload-less NON message to the group with the MCBlock1 option: SZX=its proposed block size exponent, P=1 (this is a proposal), S=0 & C=0 (no selections made)
2. The nodes that hear it, reply NON unicast, with their MCBlock1 responses; SZX=receiver's preferred SZX (same or less than sender), P=1, S=0 & C=0.
3. The sender picks one respondent, sends a UNICAST CON to that node with MCBlock1 with chosen SZX, P=0 (this is now the negotiated block size), S=1 ("I choose you") and C=0.
4. Respondent ACKs that CON message with Block1 set with a matching SZX (and block 0)… it has agreed.
5. Sender now sends to the group a NON message with MCBlock1 to the group: chosen SZX, P=0, S=0 and C=0.
6. The group nodes reply with a NON echoing the options as an acknowledgement.
7. Transfer begins using CON message Block1 with the agreed SZX … the chosen node ONLY sends the ACKs.

If the chosen node stops responding: sender sends a NON MCBlock1 C=1 unicast to that node, then goes back to step 3 to select another node… at step 4 the node responds with Block1 specifying the starting point, and the transfer resumes at step 7.

A silly protocol idea has been brewing in my mind… CoAP over AX.25.

The thinking is this… use UI frames to encapsulate CoAP messages in the same manner as UDP and use a URI scheme like coap+ax25://DEST[,DIGI1[,DIGI2…]]/[path]

If DEST has the C/H bit clear, DEST is a "multicast" group, otherwise it's a specific amateur station.

File transfer just uses RFC-7959 [block-wise transfer] (with possibly a small extension inspired by RFC-2090 [TFTP Multicast] to allow Block1 transmissions to a multicast group).

That would allow file transfer and messaging between stations using existing AX.25 packet radio hardware.

- datatracker.ietf.org/doc/html/ - CoAP RFC
- datatracker.ietf.org/doc/html/ - Blockwise transfers over CoAP
- datatracker.ietf.org/doc/html/ - TFTP Multicast
- ax25.net/ - AX.25 protocol specs and docs

Logo of the IETF
IETF DatatrackerRFC 7252: The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

The #RustLang #CoAP example of @RIOT_OS has been updated. Previously you could list processes, access sensors or read the file system. Now, you can blink LEDs, read network settings, send #IPv6 pings, and even see who pinged you.
The data formats will still need some work, right now a lot is just crude #CBOR, but it works.
github.com/RIOT-OS/RIOT/tree/m

RIOT -  The friendly OS for IoT. Contribute to RIOT-OS/RIOT development by creating an account on GitHub.
GitHubRIOT/examples/rust-gcoap at master · RIOT-OS/RIOTRIOT - The friendly OS for IoT. Contribute to RIOT-OS/RIOT development by creating an account on GitHub.

A new release has been published: RIOT OS 2024.07, nicknamed StrikinglyCrowded, is available as of today. This release of the friendly #OS for the #IoT features support for more hardware, PSA backed key storage, as well as many improvements in our #CoAP support.
A big thank you to everybody who contributed, and to Mikolai for managing this release.

Replied in thread

@b0rk In the IoT space there is #CoAP. Most of the time does responses and transmits, but can be used in spray-and-pray modes -- eg. when doing multicast discovery (never knowing whether that's all responses), or in observations. There it can just send update hoping for the best until there it hits bandwidth limits (in which case it has to start for confirmation to avoid congestion) or when the value stops changing (because eventual consistency is desired).