CODEWITHSUNDEEP
iotpublish-subscribecoap
amh9412
amh9412

Reputation: 79

CoAP pub/sub transmision reliability

I´m making a work about CoAP extension that allows it to use the Publish/Subscribe Broker model and I´m currently analyzing how is the Transmision Reliabilty gets done here. In CoAP are used CONFIRMABLE and NON-CONFIRMABLE messages, to guarantee that a message arrived to destination. My cuestion is if this extension of CoAP relies on this CoAP messages to guarantee transmision reliability, because i can´t find anything that talks about this. Thank you.

Upvotes: 0

Views: 536

Answers (2)

chrysn
chrysn

Reputation: 938

CoAP messages are not reliable and not even transmitted end-to-end -- things like token, message ID and even observation number may change in the presence of proxies.

In particular, wherever observation is used (including pub/sub), no particular representation is guaranteed to arrive at the observer; what is guaranteed (and ensured by the CON messages regularly sent as part of observations) is that on the long run, the client ends up with the same representation as the server (which is also called "eventual consistency"). This is an important feature, as it allows operation even on congested networks.

To illustrate with an example, a server may send a value "14.7" in the first place, then send "14.8" in a NON, and a proxy could forward "14.8" to the client. Then the server might send "14.9" next in a CON, which the proxy acknowledges -- but maybe the proxy is busy, and delays sending the notification to the client a bit. Next, the server sends "15.0", and the proxy forwards it immediately. You see that the client never received the "14.9", even though it was CON, but it did get a later value.

Granted, not every deployment does use proxies, but it is part of the design of REST architectures that everything in them needs to work just as well if there is any.

Upvotes: 1

Achim Kraus
Achim Kraus

Reputation: 849

In CoAP are used CONFIRMABLE and NON-CONFIRMABLE messages, to guarantee that a message arrived to destination.

CON messages are retransmitted until either the retransmission counter expires or a ACK/RST is received as answer. That makes it very probable, that the message arrives the destination, but a "guarantee" is something else. "Cut the wire" and no technology can grant, that the message arrives the destination. Receiving a ACK you could rely, that the message arrived, but if you don't receive it, you don't know it.

Retransmission consumes bandwidth, and the benefit from sending "many different" message ("unreliable") vs. "some" messages ("reliable") is application specific. That application specific decision is also true for pubsub. I'm not sure, why pubsub should therefore explicit mention the CON/NON behavior.

Just to mention: Such questions may be asked directly in the IETF Core Mailinglist. There you may reach the authors of the RFC and you have a chance, to get their feedback. You will need to register there.

Upvotes: 1

Related Questions