[OASIS Issue Tracker] (MQTT-605) Should packets be identified as multicast or unicast exclusively?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=83983#comment-83983 ] 

Andrew Banks commented on MQTT-605:
-----------------------------------

My primary concerns are that Datagrams might be either broadcast, multicast or unicast
in a way that is not completely specified by the protocol. This will lead to implementation specific
interpretations being put on these actions and might either break some implementations
or cause them to exhibit unexpected behaviour. If these behaviours are not prohibited,
then they cannot be added to the protocol in the future without the risk of breaking some implementations.

Â

Instead of trying to define whether a packet must be broadcast multicast or unicast, perhaps
we can proceed by saying whether a packet must be in the context of a session, or not.
Packets within the context of a session must be identified with exactly one session and we accept that 
because MQTT-SN is connectionless we cannot precisely say whether a session exists or not.
To achieve this we would need to rewrite the following...

3.1.15 PUBLISH OUT OF BAND

Replace 
This packet is used by both clients and gateways to publish data for a certain topic.

with

PUBLISH OUT OF BAND can be broadcast, multicast or unicast so that it is received by zero or more Clients and Gateways,
with or without a Session having been established. 
Each receiver can choose to either process or discard the packet.

==> Do Gateways process the packet as if it had been sent in the context of all of their active+inactive sessions?
 They will have to store the message for latter processing in the inactive sessions. Presumably they MUST NOT process Packets sent by other Gateways.
==> There is a problem with Topic Alias because it is only meaningful in the context of a Session. In a gateway, different Clients
 may use the same alias to map to different topicNames.


4.2 Networks & Transport Layers

Replace

o The MQTT-SN V2.0 implementation may use either the origin network address or the sender identifier in the PROTECTION 
 Packet to determine the identity of the Virtual Connection.

with

o The MQTT-SN V2.0 implementation has to associate the CONNECT, CONNACK WILLTOPICREQ, WILLMSGREQ,
 WILLTOPIC, WILLMSG, AUTH, REGISTER, REGACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, 
 SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP, DISCONNECT, WILLTOPICUPD,
 WILLTOPICRESP, and associated PROTECTION packets with a Session.
 It is free to use either the origin network address or the sender identifier in the PROTECTION Packet or
 some other means to determine the identity of the Session.

==> We have to put back the idea of there being only one Virtual Connection associated with the Session at a time,
 otherwise we create another way that Packets can get reordered. If the Virtual Connection is deemed to have 
 ended by either end, then a new Virtual Connection is started by the Client flowing a CONNECT Packet.


Also replace

The following transport protocols are also suitable but if not capable of multicast/broadcast the implementation
of the optional ADVERTISE, SEARCHGW, GWINFO packets may not be possible and also the multicast/broadcast of the PUBLISH MINUS -1
packets may not be possible:

with

ADVERTISE, SEARCHGW, GWINFO, PUBLISH OUT OF BAND and PUBLISH MINUS -1 packets can be broadcast, multicast or unicast 
outside the context of a Session and may be received by zero or more Gateways and Clients. The receiver can choose 
whether or not it processes the packet.

==> Can a Gateway process a Packet for some clients, but not others?

> Should packets be identified as multicast or unicast exclusively?
> -----------------------------------------------------------------
>
>                 Key: MQTT-605
>                 URL: https://issues.oasis-open.org/browse/MQTT-605
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: MQTT-SN
>    Affects Versions: v2.0
>            Reporter: Ian Craggs
>            Assignee: Ian Craggs
>            Priority: Major
>
> In the 1.2 specification, the ADVERTISE, SEARCHGW and GWINFO are identified as being "broadcasted" to potentially multiple receivers, whereas the other packets are not. The question here is whether we should continue to identify these packets (and PUBLISH QoS -1,- or out of band) as broadcast (or multicast) only in normative text, or just call this out as implementation advice non-normatively.
> Andy Banks is concerned that if it is the latter, then interoperability could be affected.
> Ian Craggs thinks that which address to send packets on is an implementation decision, like the TCP/IP address and port of the MQTT broker in MQTT.



--
This message was sent by Atlassian Jira
(v8.3.3#803004)