Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Messagerie directe
AWS IoT Core prend désormais en charge la messagerie directe. Vous pouvez envoyer un message à un seul appareil connecté à l'aide de son identifiant client MQTT, sans que l'appareil n'ait à s'abonner à un sujet.
Auparavant, l'envoi d'un message à un appareil spécifique nécessitait de le publier sur un sujet auquel l'appareil était abonné, sans aucun moyen intégré de confirmer la livraison. L'expéditeur appelle l'API SendDirectMessage HTTP en spécifiant l'ID client du destinataire et un sujet cible. Quandconfirmation=true, AWS IoT Core délivre à QoS 1 et attend le PUBACK du récepteur avant de renvoyer une réponse positive. Cela vous donne un accusé de réception de bout en bout. La réponse de l'API et Amazon CloudWatch Logs offrent une visibilité complète sur l'état de livraison et les raisons de l'échec.
Les messages directs ne sont pas traités par AWS IoT les règles d'exécution des règles, ne sont pas mis en file d'attente pour les appareils hors ligne et ne prennent pas en charge les messages conservés.
Dans cette rubrique :
Conditions préalables
L'expéditeur et le destinataire ont tous deux besoin de mesures politiques spécifiques pour utiliser la messagerie directe. L'expéditeur doit avoir iot:SendDirectMessage l'autorisation. L'ID du client cible est spécifié comme ressource et la clé de iot:Topic condition (facultative) limite les sujets qu'un expéditeur peut envoyer des messages directs. Le destinataire doit avoir une iot:Receive autorisation sur le sujet cible. Le destinataire n'a pas besoin d'iot:Subscribeautorisation : il AWS IoT Core envoie des messages directs sans qu'il soit nécessaire de s'abonner à un sujet. Pour plus de détails et des exemples de politiques, consultezExemples de politiques de messagerie directe.
Pour connaître l'authentification et les mappages de port utilisés par les demandes HTTP, veuillez consulter Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).
SendDirectMessage API
Les expéditeurs peuvent envoyer des messages directs en envoyant des requêtes HTTP POST à une URL spécifique au client :
https://IoT_data_endpoint/connections/client_id/messages?topic=topic_name&confirmation=true&timeout=10
-
IoT_data_endpointest le point de terminaison des données de l'AWS IoT appareil. Consultez AWS IoT données de l'appareil et points de terminaison de service pour trouver votre point de terminaison. -
client_idest l'identifiant unique du client MQTT auquel envoyer le message. Les identifiants clients ne doivent pas dépasser 128 caractères et ne peuvent pas commencer par le signe dollar ($). Les identifiants des clients MQTT doivent être codés en URL (en pourcentage) lorsqu'ils contiennent des caractères non valides dans les requêtes HTTP, tels que des espaces, des barres obliques (/) et des caractères. UTF-8 Pour plus d'informations, consultez les rubriques Courtier de AWS IoT Core messages et limites et quotas de protocole. -
topic_nameest le sujet sur lequel le destinataire reçoit le message, URL-encoded. Ne doit pas commencer par $. Il ne doit pas s'agir d'un sujet AWS IoT Core réservé. Reportez-vous à la page des quotas de AWS IoT Core service pour connaître les limites de longueur et de profondeur des sujets. Pour plus d'informations, consultez les rubriques Courtier de AWS IoT Core messages et limites et quotas de protocole. -
confirmationest un booléen. Lorsqu'elle est définie surtrue, l'API envoie le message à QoS 1 et attend que le client MQTT envoie une confirmation de livraison (PUBACK) avant de renvoyer une réponse positive. Si la confirmation de livraison n'est pas reçue dans le délai spécifié, l'API renvoie le protocole HTTP 504. -
timeoutest un entier qui représente le temps maximal, en secondes, d'attente d'une confirmation de livraison (PUBACK) du client destinataire après la remise du message. Ce paramètre n'est utilisé que lorsqu'ilconfirmationest défini surtrue. Dansconfirmationl'affirmativefalse, ce paramètre est ignoré. Le temps de réponse total de l'API peut être supérieur à cette valeur en raison du traitement interne. Définissez le délai d'expiration de votre client HTTP sur une valeur supérieure à ce paramètre.
Codes d'état de réponse de l'API
Le tableau suivant répertorie les codes d'état HTTP renvoyés par l' SendDirectMessage API et les actions recommandées pour chacun d'entre eux. Activez AWS IoT Core CloudWatch les journaux pour consulter les journaux SendDirectMessage d'événements détaillés, y compris le champ de motif pour la gestion des erreurs de programmation.
| Code HTTP | Action recommandée |
|---|---|
| 200 OK | Si une confirmation de livraison a été demandée avecconfirmation=true, cela indique que le destinataire a accusé réception du message. Dans le cas contraire, cela indique que le message a été envoyé avec succès. |
| 400 Requête erronée | Cela signifie que l'un des paramètres n'est pas valide. Passez en revue le message de réponse HTTP ou CloudWatch les journaux afin d'identifier une défaillance spécifique et de la corriger. Assurez-vous que le nom du sujet est valide et URL-encoded correct. Client-id |
| 403 Forbidden | Cela signifie que la politique de l'expéditeur n'accorde aucune autorisation iot:SendDirectMessage sur le client et le sujet cibles, ou que la politique du destinataire n'accorde aucune autorisation iot:Receive sur le sujet. Passez en revue le message de réponse HTTP ou les CloudWatch journaux pour identifier une défaillance spécifique et mettez à jour la politique correspondante. Consultez Exemples de politiques de messagerie directe. |
| 404 – Non trouvé | Cela signifie que l'ID du client cible n'est pas connecté à AWS IoT Core. Consultez le message de réponse HTTP ou CloudWatch les journaux pour la raison précise, vérifiez que le récepteur est connecté, puis réessayez. Si le message de réponse indique « L'ID du client cible n'est pas connecté, mais il possède une session permanente active », le client cible dispose d'une session persistante non expirée mais est actuellement hors ligne. |
| 413 Charge utile trop importante | La charge utile dépasse la taille maximale autorisée. Réduisez la taille de la charge utile et réessayez. Consultez Quotas de service AWS IoT Core. |
| 429 Trop de demandes | Cela signifie que le compte a dépassé la limite de SendDirectMessage demandes par seconde ou que la connexion du destinataire a dépassé la limite de publication sortante. Passez en revue le message de réponse HTTP ou CloudWatch les journaux pour la raison précise, réduisez le taux de demandes et implémentez un backoff exponentiel. Consultez Quotas de service AWS IoT Core. |
| 500 Erreur de serveur interne | Cela indique une erreur inattendue côté serveur. Réessayez la demande avec un retard exponentiel. Si le problème persiste, contactez le AWS Support à l'aide du TraceID indiqué dans la réponse. |
| 5.0.4 Délai d'expiration de la passerelle | Cela signifie que le récepteur n'a pas envoyé PUBACK dans le délai spécifié. Augmentez la valeur du délai d'attente, vérifiez que le client MQTT du récepteur envoie des messages PUBACK pour QoS 1 ou vérifiez si le récepteur traite les messages lentement. |
Exemples
Comportement du client récepteur
La messagerie directe envoie des messages aux clients MQTT (récepteurs) sans abonnement à un sujet. Pour tirer pleinement parti de la messagerie directe, le destinataire doit adopter les comportements suivants :
-
Recevoir des messages sur des sujets auxquels le destinataire n'est pas explicitement abonné — La messagerie directe du destinataire peut envoyer des messages sur des sujets auxquels le destinataire n'est pas explicitement abonné. Cependant, certaines implémentations de clients MQTT filtrent ou suppriment les messages sur des sujets non abonnés. Si votre client rejette ces messages, la messagerie directe ne fonctionnera que sur les sujets auxquels le destinataire est également abonné. Pour recevoir des messages directs sur n'importe quel sujet, vérifiez que le gestionnaire de messages de votre client traite les messages quel que soit l'état de l'abonnement.
-
Gérer la QoS déterminée par l'API — Le niveau de QoS du message délivré est défini par le
confirmationparamètre de la demande d'API de l'expéditeur, et non par l'abonnement du destinataire. Lorsqueconfirmation=truele message arrive à QoS 1, le client du destinataire doit envoyer un PUBACK pour accuser réception. Quandconfirmation=false, le message arrive à QoS 0 sans qu'aucun accusé de réception ne soit requis. Assurez-vous que l'implémentation MQTT de votre client gère correctement les messages entrants QoS 0 et QoS 1.
