配達は保証されますか?,
配達の順序は保証されます。これは、Bluetooth プロトコルの下位層に組み込まれている確認応答/シーケンス番号付けスキームによるものです。そのため、下位層では、確認応答されるまでパケットが再送信されます。これは ARQ スキームを停止して待機するのと同じであることに注意してください。タイムアウトを超えると、接続が失われたと見なされます (通常は 30 秒)。
データの完全性は保証されていますか?
Bluetooth 4.2 では BT セキュア接続が導入されました。これには、送信される各パケットのメッセージ整合性チェック (MIC) が含まれ、受信側での MIC の不一致により再送信がトリガーされ、多数の MIC の不一致により接続が切断される可能性があります。
そのため、セキュア接続機能を使用していない場合、整合性は保証されません。データを保護するために 16 ビットの CRC スキームが使用されていますが、長期間にわたって CRC エスケープ (CRC が正しいままになるようにビットが反転する) が発生することが知られています。しかし、これは比較的まれで、騒がしい環境で発生します。アプリケーションが非常に高いデータ整合性を必要とする場合は、SecureConnection を使用するか、アプリケーション レベルの整合性チェックを導入します。
SPP プロファイル自体にはエラー/シーケンス チェックがないことに注意してください。RFCOMM には、ヘッダーの破損をチェックする 8 ビット FCS (フレーム チェック シーケンス) があります。L2CAP ストリーミング/再送信モードには、L2CAP ヘッダーとデータをカバーするオプションの 16 ビット FCS があります。基本的な L2CAP モードには FCS がまったくないことに注意してください。
L2CAP FCS を有効にするオプションがある場合、下位レベルの 16 ビット CRC + L2CAP 層の 16 ビット FCS + RFCOMM レベルの 8 ビット FCS は、ほとんどのアプリケーションに十分なデータ整合性を提供します。ただし、前述のように、それが本当に重要な場合は、追加のアプリケーション レベルの整合性チェックを導入する必要があります。