2つのリモートコンピューター間の（時計の）同期

StackOverflow https://stackoverflow.com/questions/389417

  •  23-08-2019
  •  | 
  •  

質問

私はアプリに簡単な同期能力を書くことを検討していますが、ポップアップした懸念の1つは、2つのリモートコンピューター間の時間の同期です。

私はこのトピックについて多くの研究が行われており、理論的になりすぎたくないと確信していますが、リモートクロック間の時間的矛盾を最小限に抑えるために受け入れられているベストプラクティスがあるかどうか疑問に思っていますか？

たとえば、スタートは、タイムゾーンの問題を回避するため、常にユニバーサルタイム（UTC）を使用することですが、2つのコンピューターがまったく同じシステム時間を持つという保証はありません。幸いなことに、私がしている仕事はあまりきれいではないので、それはひどく重要な懸念ではありませんが、それでも私はまだ興味があります。

解決策の1つは、ローカルシステムクロックではなく、グローバルタイムサーバーなど、両端で常に同じクロックを使用することです。おそらく、これ（共有リソースロックと組み合わせて）は、同期された時間の偶発的なオーバーラップを保証することはできませんが、それはあまり実用的ではありません。

頭の中に飛び込んだだけで、おそらくグローバルタイムサーバーでシステムクロックのオフセットを計算することにより、前のポイントで計算されたオフセットと各ノード（各クライアント）を同期することです。オフセット自体が短期間で大きく変化することはないため、これは時々行う必要があります。

アップデート： 2つのコンピューターのシステムクロックを実際に同期することに興味がないことを追加しましょう。ほとんどの場合、オペレーティングシステムがこれを処理すると推測されます。これは、アプリケーションの2つのインスタンスが同期された時間を使用していることを確認する方法の単なる問題ですが、この時代と年齢では、とにかく非常に小さなデルタ内でシステムクロックがほぼ同期されると思います。

役に立ちましたか？

解決

他の人が推奨しているように、アプリケーションにNTPに依存するのは簡単です。正しいアプローチは、Lamportの分散時計同期アルゴリズムを使用することです。彼の古典的な1978年の論文で説明されています 分散システムでの時間、時計、およびイベントの順序付け.

他のヒント

見る "ネットワークタイムプロトコル「（NTP）仕様。

PTPを試すことができます。PrecisionTime Protocol（PTP）は、コンピューターネットワーク全体でクロックを同期するために使用されるプロトコルです。ローカルエリアネットワークでは、サブマイクロ秒範囲でクロック精度を実現し、測定および制御システムに適しています。http://en.wikipedia.org/wiki/precision_time_protocol

クロックを同期するコードを作成する代わりに、両方のマシンでNTPクライアントを実行するだけではありませんか？

あるいは、上記が不可能で、アプリが時間を設定するのに十分な特権で実行されている場合、アプリケーションに最小限のNTPクライアントを実装し、パブリックサーバーと同期しようとするように誘惑されます。誰かのプライベートサーバーをハードコードしないでください...

それらを同期します NTP ネットワークタイムプロトコル。

どんなプラットフォームにいますか？

NTPを使用すると、コンピューターの時間を原子時計と同期させ、世界の公式時間を使用できます。

これは、以前の貢献者が行った賢明な提案を混乱させるために多くのことをすることができる洗練されていないエンドユーザーに関して、私が現在解決しなければならない問題です。洗練されていないエンドユーザーは、少なくともこれらのことを行うことができます。

1）NTP時間同期を設定できるほど十分なコンピューティング知識がありません

2）コンピューターのタイムクロックを家の時計または携帯電話の時計を正しくない

3）Windows XPでXPでNTPタイムの同期を誤って無効にし、それを再度有効にする方法を知らないか、コンピューターの日付を誤って設定します。その場合、WindowsNTPが機能しません

4）コンピューターBIOSバッテリーがフラットになっているため、PCは常に1970年に開始されます！

5）ユーザーはラップトップを海外に持ち込み、ラップトップの時計を現地時間に一時的に設定しますが、タイムゾーンを変更しないため、PCは誤ったUTC時間を返します!!!

したがって、プログラム自体は時間を管理する必要があり、もちろん最小のオーバーヘッドでそれをしたいと思うでしょう。

プログラムを実行している2人のエンドユーザーが、将来同じ絶対的な時間に何かをするためにプログラムが必要であると仮定しましょう。

私はこのスキームを提案します。これは、Cronの仕事の仕組みからいくつかのアイデアを取ります。誰かがそのアイデアの改善を提案できるなら、私は幸せです。

1）アプリケーションが起動すると、SOAPコールを介してShird Party Serverまたは独自のTimeサーバー（NTPで時間通りに維持できます）を介して、独自の内部UTC時間をNTPに同期します。

2）その後、時間を維持するためにシステムクロックから経過時間に追加されます。要件が厳しい場合は、間隔でNTP同期を繰り返す必要がある場合があります。

3）その後、アプリケーションは、時間通りに行う必要がある将来のジョブのリストを調べます。初期の仕事を知る必要があります。

4）次に、最も早い仕事よりも先に眠るスレッドを作成します。安全マージンは少なくなります。これは、要件に応じて10分前、1時間か2時間前になる可能性があります。

5）スレッドが目覚めると、さらに石鹸コールで絶対時間を再確認し、システムタイムクロックに依存して、最初のジョブが実行されるべき時間に達するまで経過時間を追加します。

6）ジョブがトリガーされるとすぐに（別のスレッドで実行）、時間監視スレッドは次のタスクタイムを計算し、その期間にわたって再び眠ります。

アイデアの強化：

1）ユーザーは、当然の仕事の前にアプリケーションを閉じることができるため、上記の同じ同期スキームを使用するバックグラウンドプロセスまたはサービスが必要になる場合があります。時間内のアプリケーション。 （Windowsでは、申請プロセスを生み出します）

2）アプリケーションが新しい、以前のジョブをその場で追加したり、ジョブを削除したりする可能性があるため、睡眠スレッドは、新しい以前のジョブ、または削除されたジョブに続いてジョブのために再計算するために延期できる必要がある可能性があります。 Win32では、イベントでタイムアウトを待っているスレッドでこれを行います。 Linuxでは、間違いなく同様のメカニズムがあることは間違いありません。

3）石鹸の呼び出しのために時間を取得するために、石鹸が送信されたときと応答が受信されたときのメモを保持します。ターンアラウンド時間が長すぎる場合、時間に頼ることができず、通話を繰り返す必要がある場合もあれば、妥協することもできます。たとえば、SOAPがコンピューターのクロックが5分速いと言っているが、石鹸の呼び出し自体が返信に時間がかかった場合、コンピューターの時計が少なくとも4分速いことを確実に言うことしかできません。

私たちが行うことの1つは、本質的にすべてのタイミング操作を「ホスト」マシンにオフロードすることです。たとえば、すべてがDBを共有する20個のサーバーがある場合は、DBの時間を使用します。セントラルサーバーと100万のクライアントマシンがある場合、クライアントマシンは何もタイミングを合わせる責任を負わないはずです。サーバー側をすべて行います。 P2Pネットワークなどの真に「分散」環境では、問題のリソース（書きたいファイルの実際のPC）を最も直接「所有」するマシンを使用して、ファイルへのアクセスを統合/制御します。

ネットワーク化されたマシンは、NTPを使用する必要があります。すべての最新のシステムには、これをセットアップする簡単な方法が含まれています。唯一の問題は、少しの精度が必要な場合は、特定のサーバーを選択することです。しかし、それはすでにミリ秒の範囲にあるので、私は気にしませんし、通常はpool.ntp.orgを指すだけです

NTPを使用しないでください。 NTPは、日付/時刻のみを取得するためのものです。

通信しないアプリ間でイベントを同期させるのに役立ちます。たとえば、アラームアプリとあなたの体。

直接通信、リソースの共有を備えたアプリの場合、Diomidisが述べたように、Lamport ClocksまたはVector Clocksを使用します。 Lamport Clocksは、イベント間の部分的な順序を達成するためにうまく機能します。ベクトルクロックは、同時イベントを特定する必要がある場合に最適です。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top