c - サーバークライアントメッセージの検証

Question

クライアントとサーバー間の通信について質問があります。TCP unixソケットを介してデータを送信したいのですが（これを行う方法を知っています）、送信されたメッセージを完全に読み取る準備ができているかどうかをテストするためのベストプラクティスがわかりません（ブロックごとではありません）。

したがって、私はこれを考えています

1. クライアントはフォーマットされたデータprintf（3）を送信し、メッセージは文字列で書き込まれて送信されます。
2. サーバーはメッセージを受信しますが、メッセージがいっぱいの場合はどうすればよいですか？メッセージが完了するまでループする必要がありますか？

だから私の考えは、次のようにメッセージに追加されて追加されるコード（またはチェックサムかもしれませんか？）を使用することです：

[確認コード] my_long_data_formatted [確認コード]

次に、サーバーは2番目の検証コードが読み取られて正常にチェックされるまで、データの読み取りを試みます。

これはクライアント/サーバー通信の適切なソリューションですか？はいの場合、検証の境界について何をアドバイスしますか？

Answer 1

TCPにはすでにチェックサム/検証が組み込まれています。したがって、メッセージが受信された場合、それは正しく受信されました。

通常、心配する必要があるのは、メッセージの長さを把握することだけです。これは、メッセージの長さを最初に送信するか、終了文字またはシーケンスを最後に置くことによって行われます。

送信者と受信者の両方がいわば「同じページ」にあることを確認するために、受信者は通常、メッセージの受信後に応答が「OK」とだけ言っている場合でも、その応答を送り返します。

この手法の例には、HTTP、SMTP、POP3、IMAPなどがあります。

Answer 2

これを行うにはいくつかの方法があるので、「適切な」解決策はないと思います。あなたの解決策はおそらくうまくいくでしょう。注意すべき点の1つは、選択した検証コードがメッセージのデータの一部として送信されないようにする必要があるということです。その場合、実際にはメッセージの終わりではありませんが、メッセージが完了したことを検出します。データがどのようになるかを知ることができない場合は、別の手法を試す必要があるかもしれません。

あなたの説明から、あなたのメッセージは可変長であるように聞こえます。もう1つの方法は、すべてのメッセージを同じ長さにすることです。これにより、完全なメッセージを取得するために毎回読み取るデータの量を知ることができます。

もう1つの方法は、最初にメッセージの長さ（2進数の32ビット数など）を送信することです。これは、メッセージの最後まで読み取るバイト数を示します。最初にこれを読み取ってデータ量を取得し、次にその量をソケットから読み取ります。

毎回同じ長さのメッセージの数が設定されている場合は、各メッセージに番号を割り当て、最初にその番号を送信してから、それを読み取ることができます。その情報を使用して、メッセージに割り当てられた番号に基づいて、読み取るデータの量を決定できます。

ソリューションに使用するために選択するものは、メッセージが可変であるか長さが固定されているか、および/またはデータとともに追加情報を送信する必要があるかどうかなどの要因に基づいている可能性があります。この場合、後続のデータに関する情報を含む固定長ヘッダーを送信する混合物がある可能性があります。長さまたはそれに続くデータのタイプのいずれか。

Answer 3

TCPによって提供されたバイトストリームのどこでアプリケーションメッセージが開始および終了するか（そして、接続されたパーティが会話をどのように進めるか）を何らかの方法で通知するアプリケーションレベルのプロトコルを確立する必要があります。

人気のある選択肢は次のとおりです。

• 固定長メッセージ。バイナリデータでうまく機能し、非常にシンプルです。
• メッセージの残りの部分の正確なサイズ（および場合によってはタイプ）を示す固定フォーマットまたはサイズヘッダーを持つ可変サイズのメッセージ。バイナリデータとテキストデータの両方で機能します。
• 区切られたメッセージ-改行などの一部の文字、または\x1特殊でメッセージの境界を示す文字。テキストデータに最適です。
• XML、S式、ASN.1などの自己記述型メッセージ。