Skip to content

Commit 121965e

Browse files
jjj-vtmsophokles73
andauthored
Specify re-connect handling for different protocols #212 (#226)
* Specify re-connect handling for different protocols #212 * OFT tags and clarifications * Small corrections * resubscribe suggestion accepted Co-authored-by: Kai Hudalla <[email protected]> * Removed unclear reconnect specification. Use only simple exponential backoff --------- Co-authored-by: Kai Hudalla <[email protected]>
1 parent 4117868 commit 121965e

File tree

1 file changed

+38
-0
lines changed

1 file changed

+38
-0
lines changed

up-l1/mqtt_5.adoc

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -235,5 +235,43 @@ When MQTT5 (broker) is used for D2D communication, the topic shall consist of on
235235
===== Sending a Message
236236
`UTransport::send(UMessage)` translates to the MQTT publish to topic `{UMessage.source.authority_name}/{UMessage.sink.authority_name}`
237237

238+
== MQTT5 Connection handling
238239

240+
=== Establishing a connection
241+
[.specitem,oft-sid="req~up-transport-mqtt5-establish-connection~1",oft-needs="impl,utest"]
242+
--
243+
To establish an MQTT connection to a broker it *MUST* be possible for a UTransport to configure the `cleanSession` and `sessionExpiry` settings.
244+
245+
Those values have some important consequences summarized shortly:
246+
247+
[cols="1,1,1"]
248+
|===
249+
| cleanSession | sessionExpiry | Consequence
250+
| true | 0 | Previous session data is deleted and state like messages, subscribtions etc. is lost if UTransport gets disconnected
251+
| true | t>0 | Previous session data is deleted and new session will buffer data for time `t` if connection is lost
252+
| false | t | Previous session including subscribtions, unreceived messages etc. is resumed and session will buffer data for time `t` if connection is lost
253+
|===
254+
255+
Using a UTransport from the cloud side to connect to an MQTT broker we recommend to use `cleanSession=true` and `sessionExpiry=0` because we assume that there will always be at least one UTransport connected from the cloud which can handle messages so there is no need for buffering.
256+
257+
Establishing an mqtt5 UTransport from a device there is no general recommendation. Using `cleanSession=true` and `sessionExpiry=0` might be best for scaling since it reduces the load on the MQTT broker. Doing this one needs to take special care for offline devices. Using `cleanSession=true` and `sessionExpiry=t` might stress the broker but the broker helps when dealing with offline devices.
258+
259+
--
260+
261+
=== Reconnection
262+
[.specitem,oft-sid="req~up-transport-mqtt5-reconnection~1",oft-needs="impl,utest"]
263+
--
264+
If a connection is lost, the UTransport *MUST* try to reconnect to the MQTT broker. If on successfull reconnect the broker sends the `sessionPresent=false` flag, the UTransport *MUST* re-subscribe to all previously subscribed topics.
265+
--
266+
267+
[.specitem,oft-sid="req~up-transport-mqtt5-reconnection-backoff~1",oft-needs="impl,utest"]
268+
--
269+
The UTransport *MUST* implement an exponential backoff strategy as defined in the following table.
270+
271+
[cols="1,1,1,1,1,1,1"]
272+
|===
273+
| Reconnect attempt | 1 | 2 | 3 | 4 | 5 | 5+
274+
| Pause | 500ms | 1s | 2s | 4s | 10s | 10s
275+
|===
239276

277+
--

0 commit comments

Comments
 (0)