データの長さが可変の場合、通常、そのデータは別のコンテナー内にフレーム化されます。つまり、実際のデータブロックの前にヘッダーがあり、受信者に受け入れるデータの量を通知します。
たとえば、HTTPは改行文字を使用してデータを区切ります。可変長メッセージがある場合、ヘッダーには「Content-length:」フィールドが含まれます。これは、ヘッダー全体が受信されたときに読み取るバイト数を正確に示します(2つの連続する新しい行を読み取るとヘッダーが停止します)。
ソケットから4バイトを読み取り、それに続くデータ量を取得してから、別の受信を実行して残りを読み取ることはまったく問題ありません。注意してください。4バイトを要求すると、ソケットによって1〜4バイトが提供される可能性があるため、4未満の場合は、戻って残りの数バイトを要求する必要があります。これは非常によくある間違いです。開発環境では、ほとんどの場合、4を要求すると4バイトになりますが、アプリをデプロイすると、ネットワークの動作が何らかの形で異なるため、一部のマシンのどこかでランダムにクラッシュします。
一般に、データの終わりに到達するタイミングを決定するためにタイムアウトに依存することは悪いアプローチです。タイムアウトを使用すると、適切に制御された開発環境で「確実に」機能するようになる可能性がありますが、これは非常に不安定なソリューションです。CPU /ディスク/ネットワークに障害が発生すると、アプリの受信が途中で停止する可能性があります。また、アプリが仕事をする代わりに一定の時間間隔でスリープしているため、データのスループットと応答性が制限されています。