Specify re-connect handling for different protocols

[jjj-vtm]

Hi,

currently there is no specification on the reconnect handling for mqtt or zenoh protocol. I think it would make sense to include it in the specifications since loosing the connection from a vehicle to a broker is quite a common case. I would suggest to use a backoff retry strategy with an increasing backoff time. For example 500ms, 1s, 2s, 4s, 8s and then stay at 8s.

For the different protocols the following things must be taken into account for the implementation. MQTT: If the connection was established with clean sessions = true than after successful reconnection the listener topics have to be resubscribed. If there was a previous session indicated via sessionPresent flag, then no re-subscription should occur. Zenoh: To my knowledge there is no session option so re-subscription must occur.

[stevenhartley]

Hi @jjj-vtm can you please push a pull request with the above proposal to mqtt_5.adoc and zenoh.adoc. @evshary tagging you for input on the subject.

[evshary]

In my understanding, Zenoh should take care of the re-subscription internally. Zenoh also provides the reconnection mechanism in the configuration. https://github.com/eclipse-zenoh/zenoh/blob/5d09cf7cb7af1c01611fa7eaeed3b9592baa9374/DEFAULT_CONFIG.json5#L46

Loop @Mallets here in case I'm wrong.

[jjj-vtm]

Spec adaption was merged