3

Bluetoothソケットの奇妙な動作が発生しています（私の意見では）。誰かがそれを明確にしてくれるかどうか知りたいです。

状況：

Bluetooth ソケットで接続された 2 つの Android アプリケーションがあります。

  • write(byte[] message)1 つ目は、出力ストリームをシンプルにします。
  • read(byte[] buffer)2 つ目は、入力ストリームをシンプルにします。

リーダー側では、1024バイトのバッファーを使用します。送信者は、受信者のバッファー サイズよりも少し大きいメッセージを送信します: 1024 + 108バイト (常に同じメッセージ)。

さて、動作は次のとおりです。

リーダー アプリでは、ほとんどの場合、1024バイトの最初のチャンクを受け取り、(予想どおり) バッファーがいっぱいになり、次に108バイトの 2 番目のチャンクを受け取ります。

しかし、非常に頻繁に (おそらく 40% の確率で) 1008バイトの最初のチャンクを受け取り、次に124バイトの 2 つ目のチャンクを受け取ります。

重要な bluetooth の概念を見逃すことを恐れているので、これを本当に理解したいと思います。最初は、メッセージ全体が受信されたかどうかを知るために、読み取られたバイト数とバッファー サイズを比較することを考えていましたが、この実験は、おそらく良い考えではないことを示しています。

誰かが私にこの振る舞いを説明できますか?

前もって感謝します。

4

2 に答える 2

2

記録のために、私は現在、ストリームの読み取り/書き込みにGoogle Guavaメソッドを使用しており、すべて正常に動作しています。

于 2014-02-24T10:40:35.480 に答える
1

私は同じことを見つけています.Bluetoothがデータをパケットではなくストリームとして送信しているためのようです.

したがって、500 バイトのパケットを 4 つ送信すると、最終的に 1600 バイトのパケットと 400 バイトのパケットが送信されるか、または私が送信した方法になる可能性があります。オーバー スタック オーバーフローの質問では、バイト配列内のランダムな値を使用して、メッセージが終了したことを通知します ( Bluetooth 経由ですべてのバイトを一緒に読み取る方法は? )。

より良い方法があるはずですが、メッセージの終わりを見つけようとするために非常にありそうもない文字セットを使用し、それを送信する各メッセージの終わりに埋め込む予定です。他のスタック オーバーフローの質問のいくつかは '\n' の使用を提案していますが、次のようにいくつかを使用することになるかもしれません。進行中の膨大な量の他のものから抽出されたものではありません）。それが役立つことを願っています!

于 2016-03-24T07:37:55.120 に答える