LLAPIのその他の機能

ARDKのその他のLLAPIネットワーク機能について学ぶ。

概要

MultipeerNetworking APIには、セッションへの参加やメッセージの送信といった機能に加え、マルチプレイヤー体験の作成を支援する機能がいくつか用意されています。

調整クロック

MultipeerNetworkingのCoordinatedClockは、サーバーで動作する時計であり、同一セッション上のすべてのクライアントがアクセスできます。クライアントがセッションに参加すると、クライアントのローカルクロックは自動的にサーバークロックとの同期を開始します。この同期プロセスは、ネットワークの不具合によって、セッション内の個々のクライアントの調整クロックのパフォーマンスが低下しないようにするために必要です。同期が完了し（クロックのSyncStatusが Stable になる）、セッション内の同期されたすべてのクライアントがクロックのCurrentCorrectedTimeに対してクエリを実行すると、30ミリ秒以内の差異で一致します。

CurrentCorrectedTime 自体はエポックや規格に準拠することを保証するものではありません。ミリ秒単位のタイムスタンプであり、実際の時間を表すためではなく、ストップウォッチやタイマーとして使用することをお勧めします（実際の時間はローカルで別の既知のクロックと比較することで確認できます）。

永続的なキーバリューストア

永続的なキーバリューストアは、メッセージと同様に、セッション内のクライアントがデータを共有するための方法です。ただし、データはサーバー側に保存され、セッションがアクティブである限り保存されます。メッセージの一時的な性質とは異なります。セッションに参加するクライアントには、セッションに現在格納されているすべてのキー値ペアの最新の状態が通知されます。この際、ペアを設定したピアや、その設定日時は関係ありません。

キー値ペアの設定

キーと値のペアは、 string （キー）と byte[] （値）で構成されます。

using Niantic.ARDK.Networking;

void SetKeyValuePair(IMultipeerNetworking networking)
{
  string key = "my_key";
  byte[] value = new byte[10];

  // ...populate value array with content, empty values may not get persisted...

  // Stores the above data as a key-value pair on the server
  networking.StorePersistentKeyValue(key, value);
}

データシリアライズの詳細については、データをシリアライズするもあわせてご覧ください。

アップデートの取得

メッセージングAPIと同様に、格納されたキー値によって、PersistentKeyValueUpdatedイベントが表示されます。

using Niantic.ARDK.Networking;
using Niantic.ARDK.Networking.MultipeerNetworkingEventArgs;

void SubscribeToKeyValueUpdates(IMultipeerNetworking networking)
{
  networking.PersistentKeyValueUpdated += OnPersistentKeyValueUpdated;
}

// This will be fired once per key-value update, including keys that the local peer sets.
void OnPersistentKeyValueUpdated(PersistentKeyValueUpdatedArgs args)
{
  // Copy the value of the stored KV into local variables
  byte[] value = args.CopyValue();
  string key = args.Key;

  // Log some information about the key-value
  Debug.LogFormat
  (
    "Got a Persistet Key-Value. Key: {0}, Length: {1}",
    key,
    value.Length
  );

  // Do something with the value, depending on key
}

キー値ペアを実際に格納したピアに関する情報は公開されません。

結果整合性モデル

複数のピアから同一キーに書き込みがあると、サーバーが格納リクエストを受け取る順序によって決まる"Last Write Wins（最後の書き込みを優先させる）"ルールが適用されます。

さらに、キー値の更新を受け取るクライアントには、結果整合性ルールが適用されます。

この動作について説明するために、3つのクライアントが単一のキーにインクリメント値を素早く書き込んでいるとします（つまり、それぞれが1～100の数字を順次格納している）。サーバーが昇順でリクエストを受け取ると仮定すると、サーバーは最後の格納リクエスト（「最後の書き込み」）で値100を受け取ることになります。

サーバーが300件の格納リクエストを受け取った場合でも（必ずしもすべて処理されるとは限らない）、すべてのクライアントが1～99の任意の値の更新を受け取る保証はありません。更新をすべて受け取る場合や、一部のみ受け取る場合、一切受け取らない場合が考えられます。受け取る場合は昇順になります。その理由は、サーバーが格納リクエストを受け取る順序が昇順であるためです。

ただし、キーへの書き込みがなくなると、結果整合性により、最後の書き込み（100）はすべてのクライアントに送信されます。