クライアントが知っていることの利点は、パッケージがサーバーによってどれくらい送信されたかです。

Question

私はネットワークプログラミングでは本当に新しいので、これは完全な初心者質問ではないと思います。
私は少しサーバーを構築する方法のQtのホームページでチュートリアルを読んで、私はthisが見つかりました：

QByteArray block; 
QDataStream out(&block, QIODevice::WriteOnly); 
out << (quint16)0; 
out << "..."; // just some text 
out.device()->seek(0); 
out << (quint16)(block.size() - sizeof(quint16)); 

当社QByteArrayの開始時に、我々は含まれています16ビット整数のためのスペースを確保します送信するデータブロックの合計サイズ。 [ランダムなストーリーでストリーミングを続けます。]次に、QByteArrayの先頭に戻り、予約された16ビット整数値を配列の合計サイズで上書きします。 これにより、クライアントは、パケット全体を読み取る前にどれだけのデータが期待できるかを検証する方法を提供します。

この手順の利点は何ですか？あなたがそれをしないとどうなるでしょうか？多少の例を追加することもできます。

Answer 1

これは標準的なものです。

受信プログラムには、ネットワーク経由のすべてのものが単なるバイトストリームです。ストリームは、アプリケーションがそれに課す意味を超えています。アプリケーションがレコード、行などを定義する方法を超えて、ファイルが意味をなさないのとまったく同じ方法です。 クライアントとサーバーがストリームを理解できる唯一の方法は、それらが同意する規約またはプロトコルを確立することです。

だから、これを実現するためのいくつかの一般的な方法はである：

• メッセージ（例えばキャリッジリターン）
• の終了を指示する区切り文字を持っているが、あなたの例のように、長さフィールドを通過し、そのどのくらいのデータが次のメッセージを構成するかを受信側に伝えます。
• ただ単にによって流れのように扱う（すべてのメッセージはタイプ「B」は別のものを記録し、「」レコードは1つの定義された形式になります20バイトまたはタイプになります...例えば）
• 一定の規則を確立します（例えば、ネットワークを介して来るものは何でも取ると、それが何であるかに注意を払ってO/Wファイルに入れて）全く規則を持たない長さのバイト方式の

一つの利点は、受信機が正確にを知っていることですどのくらいのデータを期待するか。いくつかのサニティチェックを追加することで、アプリケーションのバッファオーバーフローなどをなくすことができます。

Answer 2

受信する前にパケットサイズを知ることは、パフォーマンス上の利点があります。 これで、ヒープまたは使用するバッファ管理から必要なバイト数を正確に割り当てて、「ネットワーク受信機能」への少数（理想的には1つ）の呼び出しをすべて受信することができます。 サイズがわからない場合は、メッセージのごく一部分だけ「ネットワーク受信機能」を呼び出す必要があります。

「ネットワーク受信機能」（recv（）やQtが提供しているかもしれない）は、TCPバッファ処理なども行うシステムコールであるため、コールオーバヘッド。だから、できるだけ少なくする必要があります。