2015-10-28 15 views
0

Мы работаем над приложением, которое будет использовать SPP (профиль последовательного порта) через Bluetooth, и разработчики обсуждают использование определенного типа протокола и доставки пакетов, а не просто передают данные без какой-либо формы ACK, последовательность или информацию о размере.Связь между последовательным портом Bluetooth (SPP)

Обеспечивает ли Bluetooth гарантированную доставку и целостность данных, так что нам не нужны накладные расходы на разработку протокола пакетов? Можем ли мы полагаться только на Bluetooth, чтобы обеспечить доставку данных?

+0

[Этот ответ] (http://stackoverflow.com/questions/14498530/bluetooth-android-rfcomm-spp-error-handling-suggestions) относится к Android, но в более общем плане применяется к SPP. – kaylum

+0

Спасибо! Это было полезно! :) – BravoZulu1

ответ

1

По существу, у BT есть свои механизмы безопасности для передачи. Тем не менее, и это так же важно - я приказываю ВАМ знать, когда начнутся и заканчиваются данные, вы должны использовать передачу типа пакета, такую ​​как STX и ETX, чтобы разграничить каждый пакет. Существуют ключи, которые придерживаются плохой привычки повторять последний отправленный байт, если в передаче есть промежуток времени, но они прекратятся при столкновении с ETX или EOT. И для вашей безопасности системы вы также можете включить контрольную сумму в конце пакета. Тогда вы вполне уверены.

0

гарантируется доставка ?,

Порядок доставки гарантируется. Это связано с схемой нумерации подтверждения/последовательности, встроенной в нижние уровни протокола Bluetooth. поэтому на более низком уровне пакет повторно передается до тех пор, пока он не будет подтвержден. обратите внимание, что это эквивалентно остановке и ожиданию схемы ARQ. если требуется больше времени ожидания, соединение считается потерянным (обычно 30 секунд)

гарантируется целостность данных?

Bluetooth 4.2 представляет собой безопасное соединение BT. Это включает в себя проверку целостности сообщения (MIC) с каждым переданным пакетом, а несоответствие MIC на принимающей стороне приведет к повторной передаче, и несколько несоответствий MIC могут отключить соединение.

поэтому, если вы не используете функцию безопасного подключения, целостность не гарантируется. Существует 16-битная CRC-схема, используемая для защиты данных, но известно, что в течение длительного периода времени будут выполняться escape-последовательности CRC (бит переворачивается таким образом, что CRC остается верным). но это относительно редко и происходит в шумной среде. если ваше приложение требует очень высокой целостности данных, то либо используйте SecureConnection, либо выполните проверки целостности уровня приложения.

Обратите внимание, что профиль SPP сам по себе не имеет проверки ошибок/последовательности, RFCOMM имеет 8-битную FCS (последовательность проверки кадров), которая проверяет повреждение заголовка. Режим потоковой передачи L2CAP/Retransmission имеет дополнительный 16-битный FCS, который охватывает заголовок и данные L2CAP. Обратите внимание, что в базовом режиме L2CAP FCS отсутствует.

Если у вас есть возможность включить L2CAP FCS, тогда у вас есть 16-битный CRC на уровне ниже + 16 бит FCS на уровне L2CAP + 8 бит FCS на уровне RFCOMM обеспечит целостность данных, которая достаточно хороша для большинства приложений , Однако, как упоминалось ранее, если это действительно важно, вам необходимо ввести дополнительные проверки целостности уровня приложения.

 Смежные вопросы

  • Нет связанных вопросов^_^