Aws-iot-device-sdk-python-v2: настроить офлайн-публикацию в v2

Текущее поведение:

• Все опубликованные сообщения ставятся в очередь перед отправкой, независимо от того, находится ли клиент в автономном режиме или в сети.
• Когда клиент подключается (или если он уже подключен), сообщения из очереди отправляются по порядку.
• ОДНАКО: если клиент БЫЛ онлайн и переходит в автономный режим, в этот момент он отменяет каждую ПУБЛИКАЦИЮ и ПОДПИСКУ в своей очереди.

Мы понимаем, что это непоследовательно. Пользователь, вероятно, захочет:
1) сообщения всегда ставятся в очередь, пока они не будут отправлены
2) сообщения не работают, если клиент отключен, или отключается до отправки.

Мы очень активно рассматриваем возможность изменения этого. Я буду держать эту проблему открытой, и мы будем обновлять, когда внесем изменения (или формализуем текущее поведение)

Если вы хотите полностью контролировать свою судьбу прямо сейчас, вы можете создать собственную очередь, которая отправляет клиенту 1 сообщение за раз. Если удастся, то отправьте следующее. Если это не удается, попробуйте еще раз. Это также дает вам возможность полностью контролировать продолжительность постановки сообщения в очередь, количество сообщений, которые будут поставлены в очередь, и т. Д.

Если вы хотите полностью контролировать свою судьбу прямо сейчас, вы можете создать собственную очередь, которая отправляет клиенту 1 сообщение за раз. Если удастся, то отправьте следующее. Если это не удается, попробуйте еще раз. Это также дает вам возможность полностью контролировать продолжительность постановки сообщения в очередь, количество сообщений, которые будут поставлены в очередь, и т. Д.

Привет @graebm. Как бы вы это сделали? Если мое устройство публикует сообщения, но находится в автономном режиме, я бы подумал, что эти сообщения остаются в очереди сомов? Есть ли способ получить доступ к этой очереди и удалить из нее определенные сообщения, если они еще не опубликованы?

Спасибо

@samvandamme вы можете установить качество обслуживания (qos) не более одного раза (0).
qos=mqtt.QoS.AT_MOST_ONCE
На том же устройстве подпишитесь на тему, в которой вы публикуете. Затем, чтобы убедиться, что сообщения отправлены, вы ведете список опубликованных вами сообщений. Удаляйте их только после того, как получите сообщение по теме.

Текущее поведение:

• Все опубликованные сообщения ставятся в очередь перед отправкой, независимо от того, находится ли клиент в автономном режиме или в сети.
• Когда клиент подключается (или если он уже подключен), сообщения из очереди отправляются по порядку.
• ОДНАКО: если клиент БЫЛ онлайн и переходит в автономный режим, в этот момент он отменяет каждую ПУБЛИКАЦИЮ и ПОДПИСКУ в своей очереди.

Мы понимаем, что это непоследовательно. Пользователь, вероятно, захочет:

1. сообщения всегда ставятся в очередь, пока не будут отправлены
2. сообщения не работают, если клиент отключен, или отключается до отправки.

Мы очень активно рассматриваем возможность изменения этого. Я буду держать эту проблему открытой, и мы будем обновлять, когда внесем изменения (или формализуем текущее поведение)

Если вы хотите полностью контролировать свою судьбу прямо сейчас, вы можете создать собственную очередь, которая отправляет клиенту 1 сообщение за раз. Если удастся, то отправьте следующее. Если это не удается, попробуйте еще раз. Это также дает вам возможность полностью контролировать продолжительность постановки сообщения в очередь, количество сообщений, которые будут поставлены в очередь, и т. Д.

Итак, каков рекомендуемый подход к работе с устройствами, отключенными на некоторое время?

Предположим, у меня есть устройство, отправляющее сообщения каждые 5 секунд, устройство подключено к сети, сообщения достигают AWS IoT Core. Затем устройство потеряло соединение на 10 минут, а затем снова подключается к сети. Что происходит со всеми теми сообщениями, которые пытались опубликовать в течение 10 минут автономного режима? Публикуются ли они, как только устройство снова выйдет в сеть, или потеряны навсегда?

Первые несколько сообщений будут потеряны, пока SDK не осознает, что он больше не отключен. Все последующие сообщения будут сохранены в очереди и отправлены при восстановлении соединения.

При тестировании я потерял первые 5 сообщений при использовании pubsub, который отправляет сообщения каждую секунду. Таким образом, большую часть времени вы теряете только одно сообщение.

Я тоже хотел бы разобраться в этом поподробнее. Как упоминалось выше, сообщения, опубликованные в автономном режиме, помещаются в очередь, а затем публикуются, когда соединение возвращается в онлайн.

Сколько сообщений хранится в офлайн-очереди? Предыдущий SDK позволял вам выбирать: бесконечное, нулевое или указанное количество. Я не могу найти никакой документации по этому поводу. Это звучит бесконечно, но я хотел бы знать. Предыдущий SDK также позволял выполнять переход с начала или с конца очереди. Возможно ли это сейчас?

Предыдущий SDK также позволял вам выбирать скорость слива сообщений, хранящихся в очереди. Теперь это можно настроить? Если нет, то какова стоимость?