ソケットライブラリでrecvを呼び出すときに、recvバッファーの大きさ

Cのソケットライブラリについていくつか質問があります。質問で参照するコードスニペットを次に示します。

char recv_buffer[3000];
recv(socket, recv_buffer, 3000, 0);

1. recv_bufferをどのくらい大きくするかをどのように決定しますか？私は3000を使用していますが、それは任意です。
2. あれば何が起こるrecv()私のバッファよりも大きなパケットを受信しましたか？
3. もう一度recvを呼び出さずにメッセージ全体を受信したかどうかを確認し、受信するものが何もないときに永久に待機させるにはどうすればよいですか？
4. スペースが不足することを恐れずにバッファーを追加し続けることができるように、バッファーに一定のスペースがないようにする方法はありますか？たぶん、バッファへのstrcat最新のrecv()応答を連結するために使用していますか？

たくさんの質問があることは承知していますが、ご回答をいただければ幸いです。

これらの質問に対する答えは、ストリームソケット（SOCK_STREAM）を使用しているか、データグラムソケット（）を使用しているかによって異なります。SOCK_DGRAM）のます。TCP/ IPでは、前者はTCPに対応し、後者はUDPに対応します。

バッファを渡す大きさをどのようにして知るのrecv()ですか？

• SOCK_STREAM：それはあまり重要ではありません。プロトコルがトランザクション型/インタラクティブ型の場合は、予想される最大の個別のメッセージ/コマンドを保持できるサイズを選択するだけです（3000で十分です）。プロトコルがバルクデータを転送している場合、より大きなバッファーの方が効率的です。経験則としては、ソケットのカーネル受信バッファーサイズとほぼ同じです（多くの場合256kB程度）。

• SOCK_DGRAM：アプリケーションレベルのプロトコルが送信する最大のパケットを保持するのに十分な大きさのバッファを使用してください。UDPを使用している場合、一般にアプリケーションレベルのプロトコルは、約1400バイトを超えるパケットを送信するべきではありません。パケットを確実にフラグメント化して再構成する必要があるためです。

recvパケットがバッファよりも大きくなるとどうなりますか？

• SOCK_STREAM：ストリームソケットにはパケットの概念がないため、この質問は実際には意味がありません。それらは単なるバイトの連続ストリームです。バッファに余裕があるよりも多くのバイトを読み取ることができる場合、それらはOSによってキューに入れられ、次のへの呼び出しに使用できますrecv。

• SOCK_DGRAM：超過したバイトは破棄されます。

メッセージ全体を受け取ったかどうかはどうすればわかりますか？

• SOCK_STREAM：アプリケーションレベルのプロトコルにメッセージの終わりを判断する何らかの方法を組み込む必要があります。通常、これは長さのプレフィックス（メッセージの長さで各メッセージを開始する）またはメッセージの終わりの区切り文字（テキストベースのプロトコルの改行など）のいずれかです。3番目に使用頻度の低いオプションは、各メッセージの固定サイズを義務付けることです。これらの長さの値を含む固定サイズのヘッダーなど、これらのオプションの組み合わせも可能です。

• SOCK_DGRAM：1回のrecv呼び出しで常に1つのデータグラムが返されます。

スペースが不足することを恐れずにバッファーを追加し続けることができるように、一定のスペースを持たないバッファーを作成する方法はありますか？

いいえ。ただし、を使用してバッファのサイズを変更することができますrealloc()（最初にmalloc()またはcalloc()で割り当てられた場合）

TCPなどのストリーミングプロトコルの場合、ほとんどの場合、バッファを任意のサイズに設定できます。つまり、4096や8192などの2のべき乗である一般的な値が推奨されます。

バッファーよりも多くのデータがある場合は、次の呼び出しのためにカーネルに保存されます recv。

はい、バッファを増やし続けることができます。あなたはoffsetから始まるバッファの真ん中にrecvを行うことができます、あなたはそうするidxでしょう：

recv(socket, recv_buffer + idx, recv_buffer_size - idx, 0);

SOCK_STREAMソケットがある場合recv、ストリームから「最初の3000バイトまで」を取得します。バッファをどのくらい大きくするかについて明確なガイダンスはありません。ストリームの大きさがわかるのは、それがすべて完了したときだけです。

あなたが持っている場合はSOCK_DGRAMソケットを、データグラムがバッファよりも大きい場合、recvデータグラムの最初の部分、-1を返すと、バッファを満たし、かつセットはEMSGSIZEにerrnoを。残念ながら、プロトコルがUDPの場合、これはデータグラムの残りの部分が失われることを意味します-UDPが信頼できないプロトコルと呼ばれる理由の一部です（信頼できるデータグラムプロトコルがあることは知っていますが、あまり一般的ではありません-できませんでした後者をよく知っているにもかかわらず、TCP / IPファミリの1つに名前を付けます;-)。

バッファを動的に拡張するには、最初にバッファを割り当て、必要に応じてmalloc使用reallocします。しかしrecv、残念ながら、それはUDPソースからの助けにはなりません。

以下のためにSOCK_STREAMあなただけ待っバイトのいくつかを引いていると、あなたは、次の呼び出しで、より取り出すことができるため、ソケット、バッファサイズは、実際に重要ではありません。余裕のあるバッファサイズを選択してください。

以下のためSOCK_DGRAMのソケットには、待機中のメッセージの嵌合部を取得し、残りは破棄されます。次のioctlを使用して待機データグラムサイズを取得できます。

#include <sys/ioctl.h>
int size;
ioctl(sockfd, FIONREAD, &size);

あるいは、あなたは使うことができます MSG_PEEKMSG_TRUNC、recv()呼び出しのフラグとフラグをして、待機データグラムサイズを取得する。

ssize_t size = recv(sockfd, buf, len, MSG_PEEK | MSG_TRUNC);

MSG_PEEK待機中のメッセージを確認する（受信しない）必要があります。recvは切り捨てられていない実際のサイズを返します。MSG_TRUNC現在のバッファをオーバーフローさせないようにする必要があります。

その後malloc(size)、実際のバッファとrecv()データグラムだけを使用できます。

テクノロジーは常に実装固有である必要があるため、質問に対する絶対的な答えはありません。着信バッファサイズがTCP通信に問題を引き起こさないため、UDPで通信していると想定しています。

RFC 768によるとに、UDPのパケットサイズ（ヘッダーを含む）の範囲は8〜65 515バイトです。したがって、着信バッファーのフェイルプルーフサイズは65 507バイト（〜64KB）です。

ただし、すべての大きなパケットがネットワークデバイスによって適切にルーティングできるわけではありません。詳細については、既存の説明を参照してください。

最大のスループットを得るためのUDPパケットの最適サイズはどれくらいですか？
インターネット上で最大の安全なUDPパケットサイズとは

16kbがほぼ適切です。ギガビットイーサネットを使用している場合、各パケットのサイズは9kbになる可能性があります。