[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-605) Should packets be identified as multicast or unicast exclusively?
[ 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]