recv（）内の遅延

Question

私はソケットプログラミングを使って通信する2つのプログラムを持っています。当初は番号を指定します。互いの間でメッセージを交換しなければならない時間についてのホップの数である。メッセージを受け取るたびに、そのIDをメッセージに追加します。したがって、文字列は毎回サイズが大きくなります。私のプログラムは8000ホップで正常に動作していますが、プログラムp1は長さ16388の文字列を送りますが、8000を超えると、p2はソケットに16385しか読み込めないことを示します。私はioctl（）を使用して、ソケットでrecv（）の準備ができている文字の量を決定し、次にchar *変数でrecvします。

p1のsend rec2（）はp2で、p2はソケット内の16385文字だけを識別しますか？ EXのために

： P1は、長さを送信する場合（16388）

P2のみを以下の長さ（16385）

Answer 1

を受けたが、私はあなたに8個のカボチャを送信しようとしていると言います。私はテーブルの上にそれらの6を入れます。あなたは、「私は8個のパンプキンを期待しています.6時ではないと思います。最後の2個をテーブルに置くまで待つつもりです。 「一度に飛行機にあまりにも多くのカボチャが欲しいとは思っていませんが、最後の2台をテーブルに置く前に、6台のうち2台を使うまで待つでしょう。私たちは立ち往生しています。私たちはそれぞれ相手を待っています。永遠に待つよ。

すでに受信したバイトを受け入れる前に、より多くのバイトが受信されるまで待つことはできません。この理由は簡単です。ネットワークプロトコルによって、各側がもう片方を待つことはできません。 TCPは送信側がこのコンテキストで待機することを許可するので、受信側も同様に待機することができません。

受信したバイトを受け入れます。それらのいずれかを受け入れる前に、相手側がすべてを送信するのを待つ必要はありません。それ以外の場合は、相手側が最初のものを受け入れるのを待ってから、それ以上送信するとどうなりますか？

Answer 2

おそらくカーネルバッファの上限に達しています。あなたはおそらくSO_RCVBUFを受信機で増やすことができ、期待どおりに動作します：SIOCINQは最終的に未読データのフルサイズを返します。

しかし、正しく機能するようにするべきではありません。バッファを混乱させるのは、パフォーマンスを微調整したいときだけです。

カーネルに使用可能なバイト数を尋ねる必要がないように、コードを再構成する必要があります。合理的な制限（4096など）を読み、1つのアプリケーションレベルのメッセージを複数の部分に分割して処理します。メッセージの長さ/境界が必要な場合は、TCPの上に自分自身を実装する必要があります。

ここで長ヘッダーとメッセージを読むためにいくつかの愚かなコードです。

int ret, len = 0, have_read; 
have_read = 0; 
while (have_read < sizeof(len)) { 
    // This will likely always return sizeof(len) the first time. 
    ret = read(fd, ((char*)&len) + have_read, sizeof(len) - have_read); 
    if (ret <= 0) { 
     // Handle error. 
    } 
    have_read += ret; 
} 
char* buf = malloc(len); 
if (!buf) { 
    // Handle error. 
} 
have_read = 0; 
while (have_read < len) { 
    ret = read(fd, buf + have_read, len - have_read); 
    if (ret <= 0) { 
     // Handle error. 
    } 
    have_read += ret; 
} 
// Handle message in buf.