0

Windows XPプラットフォーム(i7 2.1 Ghzプロセッサ)で実行されているアプリケーションがあります。このアプリケーションは、UDPを介したマスターノードとスレーブノード間のマスター/スレーブベースの通信です。マスターは要求を送信し、スレーブノードはその応答(バーストモード)で5ミリ秒ごとにデータのパケットを送信します。各データパケットの長さはヘッダーを含めて1300バイトです。

マスターノードに戻ると、メインスレッドがデータを受信して​​キューに書き込み、並列スレッドがスレッドから読み取るようにトリガーします。

問題:次のパケットを読み取る際のWinsock APIの実行時間が非常に長いため、データがバッファーから失われています。

実行時間:Recvfrom()-200-400マイクロ秒。

Open_Sock ()
{
    socket();
    //Error check

    connect ();
    //Error Check
}

Receivethread()
{
    sock again:

    select(socket, read,write,excep,(0,0));
    //error check

    rc = recvfrom(socket,buf,len,0,&s_addr,&cln_alen)
    if(rc>0) {
        enqueue(queue,buf);
    }
}

Winsock APIは、次のパケットをフェッチするためだけにそれほど長い時間を必要としないと確信しています。しかし、実際の実行時間はどうあるべきかについての情報を見つけることができません。方向性の助けは本当にありがたいです。

4

2 に答える 2

0

おそらく、送信/受信バッファサイズとOSスケジューラの問題の組み合わせに遭遇します。Windowsプラットフォームでは、スレッド間のコンテキスト切り替えはそれほど頻繁ではないため、使用できるオプションは2つあります。

  1. サーバープロセスの優先度を上げる

    これにより、サーバーアプリケーションがキューにとどまる時間が短縮されます。

  2. 受信バッファサイズを増やします

    あなたは両端でそれをする必要があります。so_RCVBUFオプションでsetsockoptを使用できます。

    int size = 1 * 1024 * 1024;
    setsockopt(socket, SOL_SOCKET, SO_RCVBUF, (const char*)&size, sizeof(int));
    
于 2013-03-13T10:56:19.363 に答える
0

パケットの損失が問題になる場合は、TCPを使用してください。TCPを使用して、単純なループバック接続の最新ではないマシンで1ミリ秒未満の応答時間を達成しました。そこにいくつかの重要なポイント:

  • トラフィックを待機するときは、WSAEventSelect()をWaitForMultipleObjects()と組み合わせて使用​​します。これがselect()と比較して大きな違いがあるかどうかはわかりませんが、追加のイベントでスレッドを停止したい場合は、処理が簡単になります。
  • 入力を待つ前にバッファを割り当てます。これにより、レイテンシが少し短縮されます。
  • パケットごとにスレッドを作成しないようにしてください。ただし、スレッドはすでに待機しています。つまり、スレッドプールを使用してください。
  • できるだけ少ないパケットを送信するようにしてください。つまり、データ全体をメモリにアセンブルして、1回の呼び出しで送信するようにしてください。これにより、後でアセンブルされる複数のパケットのネットワークIOオーバーヘッドが回避されます。
  • また、TCPではおそらくオフにしたいと思うNagleアルゴリズムも見てください。遅延確認応答と組み合わせたNagleアルゴリズムは、レイテンシに深刻な影響を与える可能性があります。
于 2013-03-09T08:14:32.687 に答える