現在、IP 経由のテレコム アプリケーションをテストしています。raw ソケットを開き、リモート側からメッセージを受信します (msgrate@750+msgs/秒、IP を除く約 180 バイトのサイズ)。
Raw ソケットの上には、(TCP と同じように) SCTP と呼ばれるレイヤーがあり、パケットが欠落していることを時々示しています。現在、受信ノードで Wireshark を実行しており、Wireshark でそのパケットを確認できます。
ソケットの受信バッファが小さいため、IP(?) がメッセージをドロップしているように見えます。ただし、IP Pegs(netstat -sv) では、ドロップされたパケットは表示されません。ソケット受信キューを 40000 に設定しようとしましたが、成功しませんでした。
IP層のどのオプションを設定する必要があるか、または設定する必要がある特定のソケットオプションがあるかどうかについてのポインタをいただければ幸いです。
ご入力いただきありがとうございます。しかし、私たちはこの問題を「解決」することができました。以前、メッセージの読み方について説明しました。selectが戻ると、ループを実行します（読み取るRawメッセージの数（この場合は> 1）に合わせて）。1）ioctl（FIONREAD）を呼び出して、読み取るバイト数を見つけます。2）recvfromを呼び出してそのバイト数を読み取ります。3）バイトをユーザーに送信します。4）再度ループに入り、ioctl（FIONREAD）を呼び出して、手順を繰り返します。
ただし、ポイント4では、ioctl（FIONREAD）を使用して0を返します。コードには防御チェックがありました。予想通り、ioctl（FIONREAD）からの0バイトは、送信者が0ペイロードのIPヘッダーを送信したことを意味します。したがって、recvfrom（bytes to read = 0）を呼び出して、IPヘッダーをフラッシュし、selectがこれに再度設定されないようにします。
時間t0で、ioctl（FIONREAD）は読み取るバイト数として0を返します。時間t1で、recvfrom（bytes to read = 0）が呼び出されます。場合によっては、t0とt1の間に、実際のデータを使用してソケット受信キューのキューに入れ、recvFrom（bytes = 0）を呼び出したときに破棄するために使用します。
設定すると、rawMsgsToRead=1の数がこの問題を「解決」しました。しかし、私の推測では、それは私たちのパフォーマンスに影響を与えるでしょう。キュー内のオクテットを0として区別できるioctl呼び出しと、ペイロード0のIPヘッダーを区別できるioctl呼び出しですか？
いくつか質問があります。1) SCTP のどの実装を使用しており、どの OS で使用しているか。一部の SCTP 実装は、他の実装よりも堅牢です。2) SCTP はドロップされたパケットを否定応答していますか? Wireshark でギャップ ack を検索します。3) そして、wireshark でドロップされたパケットが表示されている場所は、これらが再送信ではないことを確信していますか? 4) システムのどこで Wireshark を監視していますか? アプリケーションと同じ回線上にない場合は、アプリケーションが表示しないメッセージを表示している可能性があります。5) SCTP が示しているのは正確には何ですか?
IP ソケット rx バッファがオーバーフローしていると思われる場合は、SCTP RX ウィンドウのサイズを小さくすることを検討できます。これは多くの場合、sctp スタックで構成可能です。Rx ウィンドウは、確認応答を待っている未処理のデータの量を制限し、その結果、IP バッファにある可能性のあるデータの量を制限します。また、SCTP タスクの優先順位を上げて、IP バッファからメッセージをより迅速に読み取ることもできます (これが最も簡単な方法であり、私の意見では良い方法です)。
よろしく