OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-604) Specify requirements on the underlying network transport


     [ https://issues.oasis-open.org/browse/MQTT-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Banks updated MQTT-604:
------------------------------
    Proposal: 
In Terminology, add:

Virtual Connection:
Carries the MQTT-SN data between a Client and a Gateway, or a broadcast between all Gateways and all clients.
Refer to section 3.2 Networks & Transport Layers for non-normative examples.

In 3.2 Networks & Transport Layers, replace with:

The MQTT-SN V2.0 protocol requires an underlying transport to create a Virtual Connection, 
this carries datagrams from a Client to a Gateway and a Gateway to a Client.
The underlying transport must also broadcast datagrams from a Client to all Gateways and from a Gateway to all Clients.
The datagrams carry the MQTT-SN V2.0 Packets which must be received unaltered and complete.

- The underlying transport does not need to be reliable, 
 it is expected that datagrams will be lost or delivered out of order.
- The network must not deliver a datagram more than once.
- The MQTT-SN V2.0 protocol will tolerate out of order Packets and it will retransmit lost Packets. 
- The MQTT-SN V2.0 does not tolerate
 receipt of corrupted or partial Packets and does not perform error correction.
- 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.
- The underlying network does not need to provide low latency transmission. 
- The networks may be connectionless, the virtual connections do not necessarily begin, or end. 
- The networks may be radio networks.

The MQTT-SN V2.0

Non-normative comment

TCP/IP [RFC0793], TLS [RFC5246], WebSocket [RFC6455] cannot be used for for MQTT-SN v2.0 because they do not provide 
a broadcast capability. <<++++Is this true?

Non-normative comment

UDP as defined in [RFC0768] can be used for MQTT-SN v2.0 if the Maximum Transmission Unit 
is configured to be more that the MQTT-SN Packet size used and no datagram fragmentation occurs.

The following transport protocols are also suitable:

DTLS v1.2 [RFC6347]
DTLS v1.3 [RFC9147]
Other non-IP protocols
Zigbee IEEE 802.15.4 ??

Non-normative comment

TCP ports 8883 and 1883 are registered with IANA for MQTT TLS and non-TLS communication respectively.

==> MQTT reserved both the UDP and TCP ports but prohibits the use of UDP,
 we should approach the MQTT TC to get this redesignated as MQTT/MQTT-SN. 
==> Is there a recommended way to test whether an MQTT CONNECT is being sent to an MQTT-SN Gateway
 or an MQTT-SN CONNECT is being sent to an MQTT Server?

> Specify requirements on the underlying network transport
> --------------------------------------------------------
>
>                 Key: MQTT-604
>                 URL: https://issues.oasis-open.org/browse/MQTT-604
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: MQTT-SN
>    Affects Versions: v2.0
>            Reporter: Ian Craggs
>            Assignee: Andrew Banks
>            Priority: Major
>
> The section on "Networks and Transport Layers" needs to specify the requirements on the underlying transport, as MQTT 5.0 does in the normative statement:
> A Client or Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-4.2-1].



--
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]