0

私は単純なクライアント<>サーバーのセットアップを行っており、クライアントはポート 2000 で 1 秒間に何度も UDP パケットをサーバーに送信します。サーバーには、ポート 2000 でリッスンするオープン BSD ソケットを持つスレッドがあり、ブロッキングrecvfrom呼び出しを使用してデータを読み取ります。それでおしまい。サーバー内の呼び出しの周りに簡単なティックトックタイマーを設定し、recvfromこれを Wifi 経由で実行したときの結果をプロットしました。

ベンチマーク グラフ

サーバーが Wifi 経由でアクセス ポイントに接続されている場合、recvfrom 呼び出しにも通常 0.015 秒かかるという点で同様です。ただし、パケットが送信されない短い時間 (約 0.5 秒) の無線沈黙の後、サーバーに着信する次のパケットにより、recvfrom 呼び出しに非常に長い時間がかかります (0.6 ～ 3 秒)。一連の非常に短い呼び出し (約 0.000005 秒) と、通常に戻る (約 0.015 秒)。サンプルデータは次のとおりです。

0.017361 <--normal 
0.014914
0.015633
0.015867
0.015621
...      <-- radio silence
1.168011 <-- spike after period of radio silence
0.000010 <-- bunch of really fast recvfrom calls
0.000005
0.000006
0.000005
0.000006
0.000006
0.000005
0.015950 <-- back to normal
0.015968
0.015915
0.015646

よく見ると、グラフでこれに気付くことができます。

サーバーを LAN 経由で (つまり、ケーブルを使用して) アクセス ポイントに接続すると、すべてが正常に機能し、recvfrom 呼び出しには常に約 0.015 秒かかります。しかし、Wifi では、これらのクレイジーなスパイクが発生します。

ここで一体何が起こっているのでしょうか？

PS サーバーは Mac OS X を実行しており、クライアントはどちらの場合も Wifi 経由でアクセス ポイントに接続された iPhone です。クライアントを iPad で実行してみましたが、同じ結果が得られました。アクセス ポイントは、Apple Airport Express を使用して拡張されたネットワークを備えた Apple Airport Extreme ベース ステーションです。Thompson ルーターと単純な (非 WDS ネットワーク) でも試しましたが、同じ問題が発生します。

アップデート

C# で Windows .NET のサーバー部分を書き直し、他のすべてを同じに保ちながら Wifi 経由でテストしたところ、問題はなくなりました。したがって、Mac OS X の OS/ネットワーク スタック/ソケットの問題であることが示唆されます。

4

1 に答える 1

1

あなたにはどうすることもできないと思います。いくつかのことが発生する可能性があります。

  1. WiFi MAC レイヤーは、帯域幅スロットを複数のユーザーに割り当てる必要があります。通常は、できるだけ多くのトラフィックを送信するのに十分な時間をユーザーに与えようとします。しかし、他のユーザーがビジーである間、このクライアントはトラフィックを送信できません。これはユーザーが 1 人しかいない場合でも見られますが (802.11 プロトコルの結果)、もちろん複数のアクティブ ユーザーの場合に最も顕著に見られます。
  2. IOS 自体は、ある種の省電力機能を備えている場合があり、バーストを送信するためにしばらくの間パケットをバッファリングするため、一部のサブシステムを一定期間アイドル状態に保つことができます。
  3. 干渉する他の無線信号があります。

これは完全なリストではなく、与えられた入力のみですぐに思いつくものです。

1 つ: 0.6 秒から 3 秒は、ワイヤレス ドメインでは極端に長い時間ではなく、「長い」かもしれませんが、すべてのワイヤレス通信で最大の問題の 1 つである理由があります。ほとんどの wifi AP はかなり古い仕様に基づいていることを忘れないでください。したがって、これらの数値が極端であるとは言えません (ただし、3 秒のギャップは予想されません)。

于 2012-10-02T13:28:01.480 に答える