You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -55,7 +55,7 @@ These workflows can be used individually or in combination. If they're used in t
55
55
56
56
This is the default workflow, shown as follows:
57
57
58
-
58
+
59
59
60
60
1. The client negotiates with your auth server. The auth server contains the authorization middleware, which handles the client request and signs a JWT for the client to connect to the service.
61
61
1. The auth server returns the JWT to the client.
@@ -135,7 +135,7 @@ You could also add custom claims into the access token, and these values are pre
135
135
136
136
The MQTT client sends an MQTTCONNECT packet after it establishes a WebSocket connection with the service, then the service calls an APIin the upstream server. The upstream server can auth the client according to the username and password fields in the MQTT connection request, and the TLS certificate from the client.
137
137
138
-
138
+
139
139
140
140
This workflow needs explicit configuration.
141
141
* [Tutorial - Authenticate and authorize MQTT clients based on client certificates](./tutorial-upstream-auth-mqtt-client.md)
Copy file name to clipboardExpand all lines: articles/azure-web-pubsub/overview-mqtt.md
+25-27Lines changed: 25 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,33 +8,31 @@ ms.date: 07/15/2024
8
8
ms.service: azure-web-pubsub
9
9
ms.topic: overview
10
10
---
11
-
# Overview: MQTT in Azure Web PubSub Service
12
-
13
-
## Introduction
11
+
# Overview: MQTT in Azure Web PubSub service
14
12
15
13
[MQTT](https://mqtt.org/) is a lightweight pub/sub messaging protocol designed for devices with constrained resources. Azure Web PubSub service now natively supports MQTT over WebSocket transport.
16
14
17
15
You can use MQTT protocols in Web PubSub service for the following scenarios:
18
16
19
-
1. Pub/Sub among MQTT clients and Web PubSub native clients.
20
-
1. Broadcast messages to MQTT clients.
21
-
1. Get notifications for MQTT client lifetime events.
17
+
* Pub/Sub among MQTT clients and Web PubSub native clients.
18
+
* Broadcast messages to MQTT clients.
19
+
* Get notifications for MQTT client lifetime events.
22
20
23
21
## Key Features
24
22
25
-
**Standard MQTT Protocols Support**:
23
+
### Standard MQTT Protocols Support
26
24
27
25
Web PubSub service supports MQTT 3.1.1 and 5.0 protocols in a standard way that any MQTT SDK with WebSocket transport support can connect to Web PubSub. Users who wish to use Web PubSub in a programming language that doesn't have a native Web PubSub SDK can still connect and communicate using MQTT.
28
26
29
-
**Cross-Protocol Communication**:
27
+
### Cross-Protocol Communication
30
28
31
29
MQTT clients can communicate with clients of other Web PubSub protocols. Find more details [here](./reference-mqtt-cross-protocol-communication.md)
32
30
33
-
**Easy MQTT adoption for Current Web PubSub Users**:
31
+
### Easy MQTT adoption for Current Web PubSub Users
34
32
35
33
Current users of Azure Web PubSub can use MQTT protocol with minimal modifications to their existing upstream servers. The Web PubSub REST API is already equipped to handle MQTT connections, simplifying the transition process.
36
34
37
-
**Client-to-Server Request/Response Model**:
35
+
### Client-to-Server Request/Response Model
38
36
39
37
In addition to the client-to-client pub/sub model provided by the MQTT protocols, Web PubSub also support a client-to-server request/response model. Basically Web PubSub converts a specific kind of MQTT application messages into HTTP requests to registered webhooks, and sends the HTTP responses as application messages back to the MQTT clients.
40
38
@@ -43,24 +41,24 @@ For more details, see [MQTT custom event handler protocol](./reference-mqtt-clou
43
41
## MQTT Feature Support Status
44
42
Web PubSub support MQTT protocol version 3.1.1 and 5.0. The supported features include but not limited to:
45
43
46
-
1. All the levels of Quality Of Service including at most once, at least once and exactly once.
47
-
1. Persistent session. MQTT sessions are preserved for up to 30 seconds when client connections are interrupted.
48
-
1. Last Will & Testament
49
-
1. Client Certificate Authentication
44
+
* All the levels of Quality Of Service including at most once, at least once and exactly once.
45
+
* Persistent session. MQTT sessions are preserved for up to 30 seconds when client connections are interrupted.
46
+
* Last Will & Testament
47
+
* Client Certificate Authentication
50
48
51
49
### Additional Features Supported For MQTT 5.0
52
50
53
-
1. Message Expiry Interval and Session Expiry Interval
54
-
2. Subscription Identifier.
55
-
3. Assigned Client ID.
56
-
4. Flow Control
57
-
5. Server-Sent Disconnect
51
+
* Message Expiry Interval and Session Expiry Interval
52
+
* Subscription Identifier.
53
+
* Assigned Client ID.
54
+
* Flow Control
55
+
* Server-Sent Disconnect
58
56
59
57
### Not Supported Feature
60
-
1. Wildcard subscription
61
-
1. Retained messages
62
-
1. Topic alias
63
-
1. Shared subscription
58
+
* Wildcard subscription
59
+
* Retained messages
60
+
* Topic alias
61
+
* Shared subscription
64
62
65
63
## How MQTT Is Adapted Into Web PubSub's System
66
64
@@ -76,12 +74,12 @@ In general, a server to authenticate and authorize MQTT clients is required. The
76
74
77
75
* Workflow 1: The MQTT client gets a [JWT(JSON Web Token)](https://jwt.io) from somewhere with its credential, usually from an auth server. Then the client includes the token in the WebSocket upgrading request to the Web PubSub service, and the Web PubSub service validates the token and auth the client. This workflow is enabled by default.
78
76
79
-
77
+
80
78
81
79
* Workflow 2: The MQTT client sends an MQTT CONNECT packet after it establishes a WebSocket connection with the service, then the service calls an API in the upstream server. The upstream server can auth the client according to the username and password fields in the MQTT connection request, and the TLS certificate from the client. This workflow needs explicit configuration.
82
80
<!--Add link to tutorial and configuration-->
83
81
84
-
82
+
85
83
86
84
These two workflows can be used individually or in combination. If they're used in together, the auth result in the latter workflow would be honored by the service.
87
85
@@ -97,8 +95,8 @@ You can register event handlers to get notification when a Web PubSub client con
97
95
## REST API Support
98
96
99
97
You can use REST API to do the following things:
100
-
1. Publish messages to a topic, a connection, a Web PubSub user, or all the connections.
101
-
1. Manage client permissions and subscriptions.
98
+
* Publish messages to a topic, a connection, a Web PubSub user, or all the connections.
99
+
* Manage client permissions and subscriptions.
102
100
103
101
[REST API specification for MQTT](./reference-rest-api-mqtt.md)
Copy file name to clipboardExpand all lines: articles/azure-web-pubsub/quickstarts-pubsub-among-mqtt-clients.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,8 +25,8 @@ This quickstart guide demonstrates how to
25
25
26
26
> [!NOTE]
27
27
> Except for the MQTT client libraries mentioned belows, you can choose any standard MQTT client libraries that meet the following requirements to connect to Web PubSub:
28
-
> 1. Support WebSocket transport.
29
-
> 2. Support MQTT protocol 3.1.1 or 5.0.
28
+
> * Support WebSocket transport.
29
+
> * Support MQTT protocol 3.1.1 or 5.0.
30
30
31
31
# [JavaScript](#tab/javascript)
32
32
@@ -72,7 +72,7 @@ For this quick start, you can copy and paste one from Azure portal shown in the
72
72
73
73
As shown in the preceding code, the client has the permissions to send messages to topic `group1` and to subscribe to topic `group2`.
If your client failed to connect, you could use the live trace tool for troubleshooting. See [instructions](./howto-troubleshoot-resource-logs.md#launch-the-live-trace-tool) to launch the tool.
147
+
If your client failed to connect, you could use the Azure Monitor for troubleshooting. See [Monitor Azure Web PubSub](./howto-azure-monitor.md) for more details.
148
148
149
-
You can check the connection parameters and get more detailed error messages there. For example, the following screenshot shows that the connection was rejected because it set an invalid keep alive interval.
150
-
149
+
You can check the connection parameters and get more detailed error messages from the Azure Monitor. For example, the following screenshot of Azure Log Analytics shows that the connection was rejected because it set an invalid keep alive interval.
150
+
Copy file name to clipboardExpand all lines: articles/azure-web-pubsub/reference-mqtt-cloud-events.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.topic: reference
8
8
ms.date: 07/16/2024
9
9
---
10
10
11
-
# CloudEvents Extension for Azure Web PubSub MQTT Event Handler with HTTP Protocol
11
+
# CloudEvents extension for Azure Web PubSub MQTT event handler with HTTP protocol
12
12
13
13
The Web PubSub service delivers client events to the upstream webhook using the [CloudEvents HTTP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.1/http-protocol-binding.md).
14
14
@@ -320,9 +320,9 @@ The service converts specific messages published by MQTT clients to HTTP request
320
320
321
321
#### Trigger Conditions
322
322
323
-
1. An MQTT client publishes a message to a topic in the format `$webpubsub/server/events/{eventName}`. `{eventName}` cannot contain the `/` character.
324
-
2. The MQTT client has permission to publish to that topic.
325
-
3. If the client's protocol is MQTT 5.0, and the PUBLISH packet contains a content type field, the content type value should be a valid MIME type because it will be converted to the `Content-Type` header of an HTTP request.
323
+
* An MQTT client publishes a message to a topic in the format `$webpubsub/server/events/{eventName}`. `{eventName}` cannot contain the `/` character.
324
+
* The MQTT client has permission to publish to that topic.
325
+
* If the client's protocol is MQTT 5.0, and the PUBLISH packet contains a content type field, the content type value should be a valid MIME type because it will be converted to the `Content-Type` header of an HTTP request.
Copy file name to clipboardExpand all lines: articles/azure-web-pubsub/reference-rest-api-mqtt.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ ms.topic: reference
8
8
ms.date: 07/23/2024
9
9
---
10
10
11
-
# REST API Specification for MQTT
11
+
# REST API specification for MQTT
12
12
13
13
This document clarifies the meanings of the Web PubSub data-plane REST API in the context of MQTT. The existing Web PubSub REST API documentation is focused on Web PubSub’s own protocols, which may make its application to MQTT unclear.
0 commit comments