Давайте проясним ситуацию.
Стек BLE выглядит примерно следующим образом. Стек имеет эти слои в следующем порядке:
- Link Layer
- HCl (если контроллер и хост разделены)
- L2CAP
- АТТ
- ГАТТ
- Применение
Link Layer - надежный протокол в том смысле, что все пакеты защищены CRC и e принимающим устройством признается очень пакет. Если пакет не подтвержден, он повторно отправляется до получения подтверждения. Также может быть только один выдающийся пакет, что означает, что переупорядочение пакетов невозможно. Признаки обычно не отображаются на верхних уровнях.
Уровень HCI - это протокол связи между контроллером и хостом.
Уровень L2CAP практически ничего не делает, если вы используете стандартный размер MTU 23. Он имеет заголовок длины и код типа («канал»), который указывает, какой тип пакета отправляется (обычно ATT).
На уровне ATT существует два типа пакетов, отправленных с сервера, которые не отправляются в качестве ответа на запрос клиента. Это уведомления и указания. Отправка одного уведомления или показания имеет одинаковую «производительность», поскольку тип является всего лишь тегом пакета, который отправляется по нижним уровням. Различия перечислены ниже:
Показания:
- Когда пакет индикации посылается клиенту, клиент должен подтвердить пакет, посылая пакет подтверждения, когда он получил пакет индикации. Даже если пакет индикации недействителен, подтверждение должно быть отправлено обратно.
- Верхние слои не связаны с отправкой подтверждения.
- Сервер не может отправлять новое указание, пока оно не получит подтверждение от предыдущего.
- Единственный раз, когда вы не получите подтверждение после указания, является ли ссылка удалена (вы должны получить отключенное событие), или есть некоторая ошибка в некоторых стеках BLE.
- После того, как приложение отправило указание, большинство стеков BLE подтверждают приложению, что подтверждение было получено клиентом по завершении операции индикации.
Уведомления:
- слой Нет ATT признает отсылаются.
- «Команды и уведомления, которые получены, но не могут быть обработаны из-за переполнения буфера или по другим причинам, должны быть отброшены, поэтому эти PDU должны считаться ненадежными». Однако я никогда не замечал реализации, фактически следуя этому правилу, т. Е. Все уведомления доставляются в приложение. Или я никогда не попадал в размер максимального буфера.
Уровень GATT - это в основном определение того, как использовать протокол атрибутов и определяет структуру данных БД.
Последствия
По-моему, есть несколько недостатков или проблем с BLE стандартом. Есть две вещи, которые могли бы сделать показания бесполезными и ненадежными на практике:
- Невозможно отправить ответ об ошибке вместо подтверждения.
- Тот факт, что это уровень ATT, который отправляет подтверждение непосредственно, когда он получил указание, и не приложение, когда оно успешно обработало показание.
Это означает, что если, например, некоторая ошибка или другая проблема, из-за которой стек BLE не смог отправить показание в приложение или ваше приложение разбилось, или ваше приложение обнаружило, что ваше значение недействительно, есть ни в коем случае ваше периферийное устройство не может это осознавать. Поскольку он получил подтверждение, он думает, что все в порядке.
Я не могу понять, почему они определили показания таким образом. Так как приложение не отправляет подтверждение, но на нижнем уровне, кажется, нет никакого смысла в том, чтобы подтвердить подтверждение ATT, а не просто использовать подтверждение Link Layer. Оба просто признают, что пакет был получен на полпути к месту назначения.
Если мы проведем параллельную HTTP-почту и Интернет, мы можем рассмотреть подтверждение Link Layer, когда сетевая карта получателя получает запрос и подтверждение ATT в качестве подтверждения того, что стек TCP получил пакет. У вас нет способа узнать, что ваше программное обеспечение веб-сервера действительно получило ваш запрос, и оно обработало его с успехом.
То, что уведомления могут быть удалены получателем, также является плохим. Обычно уведомления используются, если периферийное устройство хочет передать большое количество данных в центральный, а затем вы не хотите, чтобы упакованные пакеты были потеряны. Они должны были спроектировать управление потоком, чтобы Link Layer прекратил подтверждение входящих пакетов, пока приложение не будет готово к обработке следующих уведомлений. Это уже реализовано на уровнях LL + HCI + Host.
Окна
Одна интересная вещь, по крайней мере стек для Windows BLE есть, если он получает указания быстрее, чем приложение обрабатывает их он начинает падать показания, а также, несмотря на то уведомления только должно быть разрешено быть сброшен из-за «переполнения буфера или других причин». В моих тестах буферируется не более 512 указаний.
Это говорит
Просто используйте уведомление, и если вы хотите какое-то подтверждение, пусть клиент посылает пакет записи, когда он получил свои данные и весьма успешно обработки.