TCP ストリームを経由するメッセージ プロトコルを作成しようとしています。受信者は、メッセージの境界がどこにあるかを知る必要があります。
1) 固定長のメッセージ、2) 受信者がメッセージの大きさを知るためのサイズ フィールド、または 3) 一意のメッセージ ターミネータ (これはメッセージの他の場所では使用できないと思います) のいずれかを送信できます。
効率上の理由から、#1 は使用しません。
#2 は気に入っていますが、ストリームが同期しなくなる可能性はありますか?
受信者がメッセージのサイズを事前に知ることができず、ターミネータがメッセージの他の場所に表示されないようにする必要があるため、アイデア #3 は好きではありません。
＃2で、同期が外れる可能性がある場合、ターミネータを追加できますか、それとも送信者プログラムが送信する内容が正しい限り、決して同期が外れないことが保証されていますか? #2と#3を行う必要がありますか?
私にお知らせください。
ありがとう、ジブ
私はsigjuiceに同意します。サイズ フィールドがある場合は、メッセージの終わりの区切り文字を追加する必要はありませんが、良い考えです。両方を使用すると、物事がより堅牢になり、デバッグが容易になります。
サイズ フィールドと文字列の終わりの文字の両方を含む、標準のnetstring formatの使用を検討してください。サイズ フィールドがあるため、メッセージ内で文字列終了文字を使用しても問題ありません。
TCP を使用しているため、パケット配信は信頼できます。したがって、接続がドロップするか、タイムアウトするか、メッセージ全体を読むことになります。したがって、オプション 2 は問題ありません。
送信コードと受信コードの両方を最初から開発している場合は、長さヘッダーと区切り文字の両方を使用しても問題はありません。これにより、堅牢性とエラー検出が提供されます。＃2を使用する場合を考えてみましょう。Nの長さフィールドをTCPストリームに書き込んでも、Nとは異なるサイズのメッセージを送信することになった場合、受信側はそれ以上のことを知らず、混乱してしまいます。
＃2と＃3の両方を使用する場合、絶対確実ではありませんが、受信者は、TCPストリームからNバイトを消費した後に区切り文字に遭遇した場合に、メッセージを正しく受信したことをより確信できます。メッセージ内で区切り文字を安全に使用することもできます。
＃2と＃3の両方を使用する実際の例については、HTTPチャンク転送コーディングをご覧ください。
作業しているレベルによっては、#2 は実際には非同期になるという問題がない場合があります (TCP はパケットにシーケンス番号を付けており、ストリームが順不同で到着した場合に正しい順序でストリームを再構築します)。 .
したがって、＃2がおそらく最善の策です。さらに、送信の早い段階でメッセージ サイズを知ることで、受信側でのメモリの割り当てが容易になります。
興味深いことに、ここには明確な答えはありません。#2 は一般的に TCP 経由で安全であり、「現実の世界で」かなり頻繁に行われます。これは、TCP がすべてのデータが破損せず*、送信された順序で到着することを保証するためです。
*TCP チェックサムがまだパスするような方法で破損していない限り。
4 番目の選択肢があります。それは、XML などの自己記述型プロトコルです。