Applicability to multi-partcipant buses?

[chrysn]

In serial communication, a popular bus is RS485, which is a half-duplex shared bus that often looks like any other serial connection.

I think that doing this is, to some extent, feasible, and practical in some situations; whether it is worth adding to this document is unsure (so let's discuss here).

There is a simple case that I think works particularly well: If

• most of the traffic is CoAP (probably impractical for IP, but maybe get some diagnostic output, especially around errors), and
• there is only one client, and
• the servers always use piggy-backed responses and no non-traditional responses such as observation

then the system would be largely free of collisions, especially if there is a bit tighter agreement on how long after a request it is permissible to send a response, and could already be used with current implementations. All the client needs to do is send CONs and leave NSTART=1.

Servers could distinguish whether a request is for them or not by looking at a Uri-Host option, and even group messages where some Uri-Host value serves as a group name is doable thanks to Leisure.

Setups with non-traditional or separate responses would need to either "just" use little enough traffic that collisions are not an issue, or might involve some polling: The single client knows which servers it is expecting responses (of either kind) from, and can poll it. Sadly, a CoAP ping is not quite sufficient because it can't carry Uri-Host, but maybe a Signaling message would do (maybe that Ping, and similar to Custody, a pong can say "I'm here and will still send something", or "I'm here and I've said everything", or just a CON message that is just pending).

If the coordinator regularly polls all participants, they can even become clients, but at that point, things get complex, and this should be simple -- at some point it's probably better to just run 6lobac (RFC8163).