Aws-iot-device-sdk-python-v2: configurer la publication hors ligne dans v2

Créé le 31 juil. 2020  ·  6Commentaires  ·  Source: aws/aws-iot-device-sdk-python-v2

Votre demande de fonctionnalité est liée à un problème ?
Je n'ai pas vu si offline publishing était activé par défaut.

Décrivez la solution que vous souhaitez
Comme dans python sdk v1, ce serait bien de voir quelque chose comme la méthode configureOfflinePublishQueueing .

Décrivez les alternatives que vous avez envisagées
J'aurais ma propre file d'attente si le message était publié ou non.

Contexte supplémentaire
https://github.com/aws/aws-iot-device-sdk-python/blob/master/samples/basicPubSub/basicPubSub.py#L101

feature-request

Commentaire le plus utile

J'aimerais aussi comprendre cela plus en détail. Comme mentionné ci-dessus, les messages publiés hors connexion entrent dans la file d'attente, puis sont publiés lorsque la connexion est de nouveau en ligne.

Combien de messages sont stockés dans la file d'attente hors ligne ? Le SDK précédent vous permettait de choisir, infini, aucun ou un montant spécifié. Je ne trouve aucune documentation à ce sujet. Cela semble infini mais j'aimerais savoir. Le SDK précédent vous permettait également de vous retirer du haut ou du bas de la file d'attente. Est-ce possible maintenant?

Le SDK précédent vous permettait également de choisir un taux de drainage pour les messages stockés dans la file d'attente. Est-ce configurable maintenant ? Si non, quelle est la valeur ?

Tous les 6 commentaires

Le comportement actuel est :

  • Tous les messages publiés sont mis en file d'attente avant l'envoi, que le client soit hors ligne ou en ligne.
  • Lorsque le client se connecte (ou s'il est déjà connecté), les messages de la file d'attente sont envoyés dans l'ordre.
  • CEPENDANT : si le client ÉTAIT en ligne et se déconnecte, à ce moment-là, il annule chaque PUBLIER et S'ABONNER dans sa file d'attente.

Nous comprenons que cela est incohérent. L'utilisateur veut probablement soit :
1) les messages sont toujours mis en file d'attente jusqu'à ce qu'ils puissent être envoyés
2) les messages échouent si le client est hors ligne ou se déconnecte avant d'être envoyés.

Nous évaluons très activement comment changer cela. Je garderai ce problème ouvert et nous mettrons à jour lorsque nous aurons apporté des modifications (ou formalisé le comportement actuel)

Si vous voulez prendre le contrôle total de votre destin dès maintenant, vous pouvez créer votre propre file d'attente qui envoie 1 message à la fois au client. S'il réussit, envoyez le suivant. S'il échoue, réessayez. Cela vous donne également la possibilité d'avoir un contrôle total sur la durée pendant laquelle un message peut être mis en file d'attente, le nombre de messages qui seront mis en file d'attente, etc.

Si vous voulez prendre le contrôle total de votre destin dès maintenant, vous pouvez créer votre propre file d'attente qui envoie 1 message à la fois au client. S'il réussit, envoyez le suivant. S'il échoue, réessayez. Cela vous donne également la possibilité d'avoir un contrôle total sur la durée pendant laquelle un message peut être mis en file d'attente, le nombre de messages qui seront mis en file d'attente, etc.

Salut @graebm. Comment vous y prendriez-vous ? Si mon appareil publie des messages, mais qu'il est hors ligne, je pense que ces messages restent dans une sorte de file d'attente ? Existe-t-il un moyen d'accéder à cette file d'attente et d'en purger certains messages s'ils n'ont pas encore été publiés ?

Merci

@samvandamme, vous pouvez définir la qualité de service (qos) sur au plus une fois (0).
qos=mqtt.QoS.AT_MOST_ONCE
Sur le même appareil, abonnez-vous au sujet sur lequel vous publiez. Ensuite, pour vous assurer que les messages sont envoyés, vous maintenez une liste des messages que vous avez publiés. Ne les supprimez que lorsque vous avez reçu en retour le message sur le sujet.

Le comportement actuel est :

  • Tous les messages publiés sont mis en file d'attente avant l'envoi, que le client soit hors ligne ou en ligne.
  • Lorsque le client se connecte (ou s'il est déjà connecté), les messages de la file d'attente sont envoyés dans l'ordre.
  • CEPENDANT : si le client ÉTAIT en ligne et se déconnecte, à ce moment-là, il annule chaque PUBLIER et S'ABONNER dans sa file d'attente.

Nous comprenons que cela est incohérent. L'utilisateur veut probablement soit :

  1. les messages sont toujours mis en file d'attente jusqu'à ce qu'ils puissent être envoyés
  2. les messages échouent si le client est hors ligne ou se déconnecte avant d'être envoyés.

Nous évaluons très activement comment changer cela. Je garderai ce problème ouvert et nous mettrons à jour lorsque nous aurons apporté des modifications (ou formalisé le comportement actuel)

Si vous voulez prendre le contrôle total de votre destin dès maintenant, vous pouvez créer votre propre file d'attente qui envoie 1 message à la fois au client. S'il réussit, envoyez le suivant. S'il échoue, réessayez. Cela vous donne également la possibilité d'avoir un contrôle total sur la durée pendant laquelle un message peut être mis en file d'attente, le nombre de messages qui seront mis en file d'attente, etc.

Alors, quelle est l'approche recommandée pour gérer les appareils qui se déconnectent pendant un certain temps ?

En supposant que j'ai un appareil qui envoie des messages toutes les 5 secondes, que l'appareil est en ligne, les messages parviennent à AWS IoT Core. Ensuite, l'appareil a perdu la connexion pendant 10 minutes, puis se reconnecte. Que se passe-t-il avec tous ces messages qui ont été tentés de publier pendant la période hors ligne de 10 minutes ? Sont-ils publiés dès que l'appareil est à nouveau en ligne ou sont-ils perdus à jamais ?

Les premiers messages seront perdus tant que le SDK ne se rendra pas compte qu'il n'est plus déconnecté. Tous les messages suivants seraient enregistrés dans la file d'attente et envoyés lorsque la connexion serait rétablie.

Lors du test, j'ai perdu les 5 premiers messages lors de l'utilisation du pubsub, qui envoie des messages toutes les secondes. Ainsi, vous ne perdriez qu'un seul message la plupart du temps.

J'aimerais aussi comprendre cela plus en détail. Comme mentionné ci-dessus, les messages publiés hors connexion entrent dans la file d'attente, puis sont publiés lorsque la connexion est de nouveau en ligne.

Combien de messages sont stockés dans la file d'attente hors ligne ? Le SDK précédent vous permettait de choisir, infini, aucun ou un montant spécifié. Je ne trouve aucune documentation à ce sujet. Cela semble infini mais j'aimerais savoir. Le SDK précédent vous permettait également de vous retirer du haut ou du bas de la file d'attente. Est-ce possible maintenant?

Le SDK précédent vous permettait également de choisir un taux de drainage pour les messages stockés dans la file d'attente. Est-ce configurable maintenant ? Si non, quelle est la valeur ?

Cette page vous a été utile?
0 / 5 - 0 notes