8秒ごとにサーバーにパケットを送信するクライアントがあります。サーバーは、パケットの送信が速すぎることを検出すると、クライアントを切断します。クライアントでは、Sleep(8000) を呼び出します。パケットを送信する前に。サーバー側では GetTickCount(); を使用します。パケット間の時間を計算します。私はこれが問題なく動作することを期待していましたが、切断され続けています。
WireShark を使用してパケット時間を確認したところ、次のようになりました。 Packet# Time 17 8.656064 72 16.957240 115 24.764741
24.764741 - 16.957240 = 7.807501 < 8 が切断された理由です。クライアントで Sleep(8000); を呼び出すため、これがわかりません。そのため、8 秒以上ごとにパケットを送信する必要があります。
2 番目のパケットは 0.3 秒遅く、3 番目のパケットは約 0.2 秒早いです。これらのパケットを時間内に送信する方法はありますか?
クロックの精度に頼りすぎず、遅延の原因に注意するようにアドバイスする回答は正しいです。
しかし、あなたが 200ms 以内に出ているという事実は、あなたが TCP を使用しており、Nagle アルゴリズムをオフにしていないことを推測させます。時間に敏感なプロトコルの場合、TCP_NODELAY がオンになるようにソケットを設定する必要があります。
残りのすべての TCP レイテンシ警告が適用されます。いつ何が起こるかわからないので、プロトコルでそれを処理する必要があります。
問題は実際には古いものです。TickCount は、同じコンピューター内の複数の CPU 間でも異なります。
http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/22c68353-1dbb-4718-a8d2-0679fdc0c298/
私の提案は、Sleep を 8000 よりも高く、たとえば 9500 に設定し、tickCount に対して同じメカニズムを維持することです。したがって、Sleep は常に高くする必要があります。
読むための別のリンクは次のとおりです。
http://en.wikipedia.org/wiki/Latency_(engineering)#Computer_hardware_and_operating_system_latency
Microsoft Windows のパラグラフを具体的に参照してください。
アップデート：
これが反対票を投じられている理由はわかりませんが、ここで問題を明確にすることができます。
TickCount は、1 つの処理単位にローカライズされている場合を除き、特定の時間の測定値として信頼することはできません。MSDN への最初のリンクは、理由に関する引用を提供します。
次に、Windows 自体のタイマー ロジックが不正確である可能性があります。
最後に、大気条件が圧電振動に影響を与えることが知られているため、Crystal ベースのタイマーは異なる場合があります。
http://en.wikipedia.org/wiki/Crystal_oscillator#Temperature_effects
要約すると、TickCount は信頼性が低く、ネットワークを介してパケットを送信する際に絶対的な精度を得ることは、コンシューマー グレードのネットワークを介して実現するのは困難です。
私の解決策は、スリープタイマーがティックタイマーよりも長く待機することを保証することですが、問題を解決するのに十分な「ファッジ」です。
パケットが X 秒以内に到着することを保証することはできませんが、特定の期間が経過する前に送信されないことはほぼ確実です。
私には、これが機能すると期待するのは奇妙に思えます。たとえば、遅延にもかかわらず、パケットがバッファリングされ、一緒にネットワーク経由で送信される可能性があります。ネットワークの状態によっては、順不同で到着したり、任意の遅延で到着したりする可能性があります. それらがサーバー側で処理されるとき、それらの間の時間はどのくらい重要ですか? サーバー上のタイミングは、クライアント上のタイミングについては何も言いません。
ネットワーク上で送信される個々のパケットのタイミングが正確に設定されることは期待できません。最後の2つのパケット間の時間に基づいて切断条件を設定する代わりに、より長い期間にわたって平均します。たとえば、過去40秒間に5つを超えるパケットが受信された場合は切断します。