2011-11-10 15 views
1

私はWindows XPとSevenの両方のネットワークアプリケーションを開発しています。アプリケーションはUDP経由でデータを受信し、ブロッキングソケット、select(WSAPollではなく)およびrecv関数を使用します。recv()には、Win 7のソケットからすべてのUDPパケットを受信する時間がありませんか?

テスト用に、異なるLatitude D630、Core 2 Duo 2.2GHz、4Gb RAM、Broadcom NetXtreme 57xx Gigabit Controllerの2種類の同一のノートブックを使用しています。

Windows XP Professional 32bit:ネットワークモニタアプリケーションは、ネットワークインターフェイスが平均速度35Mバイト/秒でLANからデータを受信したことを示します。アプリケーションは平均速度30Mバイト/秒でソケットからデータを受信し、13%の損失を検出します。

Windows 7 Enterprise 32bit:ネットワークモニタアプリケーションは、ネットワークインターフェイスが平均速度35メガバイト/秒でLANからデータを受信することを示します。アプリケーションは、平均速度10 MB /秒でソケットからデータを受信し、65%の損失を検出します。

アプリケーションがWindows 7のソケットからすべてのパケットを受信するのに十分な時間がないように見えますが、結果がWin XPと異なるのはなぜですか?

+2

異なるハードウェアドライバである「MMCSS」は、ネットワークアクティビティを7で抑制します。受信バッファを増やすと、両方のシステムで損失率が合理的に低下するかどうかを確認したいと思います。 –

+0

私の受信バッファはソケット作成後にsetsockoptで64Kに設定されています。答えをありがとう。私はあなたのassupmtionsを確認します。 – Rom098

+1

はい、バッファサイズを増やすと受信が安定します。結果が異なる理由は、Windows 7での受信バッファサイズがWin XPよりも大きいはずです。私は256KBytesにサイズを増やし、両方の3%の損失で速度35MBpsを受け取った。ありがとうございました。 – Rom098

答えて

0

私はこのような問題に対処している人のために、次のものを提供しています。私はこの投稿に似たようなものを扱っています。私はこのことが他の誰かの時間を節約することを願っています。

@Roman Rに上記のコメントがあり、バッファサイズの変更が彼/彼女にも役立つことを示すコメントをフォローアップするために@ Rom098に感謝したいと思います。

いくつかの端末間でデータをやりとりするために、低速のUDPでWindowsソケットを使用するアプリケーションは、Windows XPでは問題なく動作していましたが、Windows 7への移行に伴い、

アーキテクチャは、クライアント端末が一連のUDPメッセージを送受信し、クライアントが独自の状態を維持することによって、サーバ端末との会話を行うというアーキテクチャです。クライアント端末は、ユーザ入力とサーバ端末へのメッセージの送受信を処理するスレッドであるクライアントスレッドを有する。サーバー端末には、他の端末からの要求メッセージとそれ自身のクライアントスレッドを処理するスレッドServer Threadがあります。クライアント端末がサーバ端末に要求メッセージを送信し

  • サーバ端末が
  • サーバ端末プロセスが要求し
  • クライアントへの応答メッセージを送信する受信確認メッセージで応答:シンプルなメッセージシーケンスは次のようになりますクライアント端末がサーバ端末に肯定応答を送る

上記のコメントを見ると、デバッガを使用して確認したところ、Windows 7には不具合がありますt WinSockは8K(8192バイト)のバッファサイズを送受信します。インターネット上で見ると、Windows XPはネットワークトラフィックの処理速度が高いようです。

私たちは、通信を扱うネットワーク層に2つの変更を加えました。

最初に、setsockopt()関数を使用して、次のコードを使用して送受信バッファのサイズを2倍にします。クライアント・スレッドは、確認応答を待っていると、応答メッセージがサーバ端末から来る場合

iOptLen = sizeof(INT); 
error = getsockopt (iSocket, SOL_SOCKET, SO_RCVBUF, (PCHAR)(&iOpt), &iOptLen); 
if (error < 0) { 
    error = WSAGetLastError(); 
} else if (iOpt < 1024 * 16) { 
    iOpt = 1024 * 16; 
    error = setsockopt(iSocket, SOL_SOCKET, SO_RCVBUF, (const PCHAR)(&iOpt), sizeof(iOpt)); 
    if (error < 0) { 
     error = WSAGetLastError(); 
    } 
} 
iOptLen = sizeof(INT); 
error = getsockopt (iSocket, SOL_SOCKET, SO_SNDBUF, (PCHAR)(&iOpt), &iOptLen); 
if (error < 0) { 
    error = WSAGetLastError(); 
} else if (iOpt < 1024 * 16) { 
    iOpt = 1024 * 16; 
    error = setsockopt(iSocket, SOL_SOCKET, SO_SNDBUF, (const PCHAR)(&iOpt), sizeof(iOpt)); 
    if (error < 0) { 
     error = WSAGetLastError(); 
    } 
} 

私たちが作った2番目の変更は、確認応答と応答の組み合わせのような応答メッセージを処理しています。私たちがやっていることは、ある時点で承認メッセージがドロップされたことを前提としています。

この2つの変更点では、サーバー端末からクライアント端末への確認メッセージが削除されていることがわかりましたが、遅れは目立たなくなりました。

も何か他のものに8Kからデフォルトのバッファサイズを変更するには、Windowsのレジストリの変更を使用しています

Change default socket buffer size under Windowsを参照してください。

What is the size of a socket send buffer in Windows?これは約TCPですが、setsockopt()に関する追加情報を提供します。

Winsock UDP packets being dropped?これは、追加の情報を提供する多くの回答で同様の問題を論じています。

Application Note: Windows 2000/XP TCP Tuning for High Bandwidth NetworksのInnominate.comにはいくつか興味深い情報がありますが、Windows 7ではネットワークレイヤーが書き直されていると分かっています。

Real time communications over UDP protocol codeproject.comのマイケルパンさんから、UDPを使用する際の技術的な問題についての詳細がかなりあります。

関連する問題