0

私のプログラムは、いくつかの UDP メッセージを受け取ります。それぞれのメッセージは、クライアントによるマウス クリックで送信されます。プログラムには、いくつかのパラメータを設定するためだけのメイン スレッド (GUI) があり、2 番目のスレッドが作成されます。

CreateThread(NULL, 0, MyFunc, &Data, 0, &ThreadTd);

UDP パケットをリッスンしています。これは MyFunc です。

... 
sd=socket(AF_INET, SOCK_DGRAM, 0);
if(bind(sd,(struct sockaddr *)&server,sizeof(struct sockaddr_in))==-1)
  ....
while(true){
bytes_received=recvfrom(sd,buffer,BUFFER_SIZE,0,(struct sockaddr *)&client,&client_length);
//parsing of the buffer
}

パケット損失がないことを証明するために、特定のポートを使用してクライアントから送信された UDP メッセージをリッスンする単純なスクリプトを使用した場合、送信されたすべてのパケットがコンピューターによって受信されます。アプリケーションを実行すると、クライアントが最初のマウス クリックを行うとすぐに UDP メッセージが受信されますが、他のメッセージ (他のマウス クリック) を送信しようとすると、サーバーはそれらを受信しません (彼がt キャッチ) とクライアント側では、サーバーがメッセージをキャッチする前に、ユーザーは少なくとも 2 回クリックする必要があります。メイン スレッドは常にビジーではなく、2 番目のスレッドは着信メッセージのみを解析し、いくつかの変数を拡張します。スレッドに優先順位を割り当てていません。

何か提案はありますか？

4

4 に答える 4

2

マークの提案に加えて、wireshark/netcat を使用して、データグラムがいつ/どこに送信されるかを確認することもできます

于 2012-09-19T15:47:39.463 に答える
0

あなたの質問を正しく理解していれば、スレッド化されたサーバー アプリは、パケットが急速に送信されたときにすべてのパケットを受信するわけではありません。試してみることができることの 1 つは、サーバー側でソケット受信バッファーを増やすことです。これにより、アプリケーションの読み取り速度が十分でない場合に、より多くのデータがキューに入れられる可能性があります。を参照してください。オプションsetsockoptを使用してください。SO_RCVBUF

于 2012-09-19T19:02:46.517 に答える
0

パケットロスの理由を知るには十分な情報がありません。最初の recvfrom に到達する前に受信スレッドに遅延がある可能性はありますか? デバッグ トレースがその方法を示している可能性があります。また、bind() を呼び出す前に、struct sockaddr サーバーに正常なものが入力されたと思いますか? あなたはその部分を見せていません...

于 2012-09-19T15:40:45.057 に答える
0

これは、ソケット プログラミングに関連する問題である可能性があります。select()への呼び出しまたはepoll()への呼び出しを組み込むことをお勧めしrecvfrom()ます。これは、ソケット プログラミングのより標準的なアプローチです。このようにして、UDP サーバーは複数のクライアントからメッセージを受信でき、無期限にブロックすることはありません。

また、クライアントがすべてのクリックに対して常にパケットを送信するとは限らないという問題があるかどうか、または何らかの理由でサーバーが常にパケットを受信するとは限らないかどうかを特定する必要があります。Wireshark は、パケットがいつ送信されるかを確認するのに役立ちます。

于 2012-09-19T15:01:20.383 に答える