dev system overview

---

id: system-overview title: システムの概要

システム概要

• https://hubs.mozilla.com/docs/system-overview.html

(訳注2021/9/28)英語版に大幅改訂がありましたが、経緯を理解する上で重要な内容が含まれていますので旧版は文末に移動して保存してあります。

クライアント

ユーザーが目にするほとんどすべてのものをレンダリングします。HTMLページはretculumによって提供されていますが、クライアントから生成されています。

フロントエンドは、2DコンポーネントにはReact、3DシーンにはThree.jsとA-Frameを使用しています。3Dコンテンツはネットワーク化されたAframe(networked aframe; NAF)を使ってクライアント間で同期されています。物理演算はAmmo.js/Wasmを使ってクライアント上で実行されます。

クライアントの各ページはバックエンドのReticulumから提供されます。/adminフォルダには、Hubsから実行するために分離された管理パネルのコードが含まれています。

networked aframe

ゲームのネットワークは、networked-aframe (NAF)ライブラリを使って実装しています。現在のところ、認可と認証はジョインやキック（参加／強制退出）のようなメッセージの小さなサブセットに強制されていますが、メッセージレベルの認可を行うための機能があります。

Ammo.js/Wasm

物理シミュレーションはすべてクライアントで行われ、サーバーサイドでの物理シミュレーションは一切ありません。サーバーは基本的にメッセージバスで、クライアントのメッセージを受け取り、若干の修正と承認を加え、メッセージとその更新を接続されたすべてのピアにブロードキャストします。オブジェクトの所有権や、ピア間でゲーム内の体験を調整するためのその他の付随的な問題などは、すべてクライアントプロトコルの実装に基づいています。

Reticulum

erlang/elixir/phoenixノードのメッシュネットワークで、すべてのトラフィック、以下のユーザー間の非音声/映像を担当します。

• アバターの移動
• 認証/マジックサインのリンク
• 復号化
• シーンの更新
• ユーザー権限の検証
• ルームに接続したとき、複数のWebsocketsで負荷分散されたロードバランスノードに接続されます。メッセージは、phoenix channelsと呼ばれるpub/subシステムを介して、メッシュ内のその部屋のすべてのユーザー間で中継されます。

Habitat

Habitatはパッケージングとオーケストレーションを提供します。デプロイメントはHabitatによってオーケストレーションされます。 すべてのAWS EC2インスタンスはHabitatを実行しており、HabitatはHubs、Reticulum、Dialogなどのパッケージを実行しています。

Dialog

Voice, video and audio traffic is handled via WebRTC Server based on the open source “mediasoup” project. (We formerly used the “Janus” project as our WebRTC server). It uses an SFU (Selective Forwarding Unit) topology where each participant is sending their data to a central routing machine which then sends back all participants data to each participant.

Postgres DB

持続的なstateを維持するために、Hubsは派手なことはしていません。耐久性のある保管方法として2つ、reticulumの後ろにはpostgresqlのデータベースがあり、さらにファイルストアがあります。reticulumはその両方を管理します。ピン・オブジェクトなどの永続的な部屋の状態を更新するときは、これらの2つのバックアップ・ストアのビットを更新するために、reticulumではAPIを使ってやり取りしています。

旧版（Discordより）

私たちのネットワークトポロジーは少し変です。 ユーザーとユーザーの通信に関連する2つのバックエンドサービスがあります。 １つは、erlang/elixir/phoenixノードのメッシュネットワークでユーザー間の非音声/動画トラフィックを担当しているReticulumです。 ルームに接続すると、このメッシュ上の負荷分散ノードにWebSocket経由で接続し、phoenix channelsと呼ばれるPub/Subシステムを介して、ルームの中にいる全ユーザー間で中継されます。 一方、音声とビデオの場合は、JanusとJanusプラグインを実行している共有SFUノードにも接続されています（したがって、すべてのユーザーが部屋で同じ物理ノードに接続され、音声/ビデオリレーが行われます）。 P2Pトラフィックはありません。 運用上すべてがopsリポジトリに取り込まれます。

私たちのゲームネットワーク自体はnetworked-aframeライブラリを使用して実装されています。 現在、承認と認証は参加やキックなどの非常に小さなメッセージのサブセットに行われていますが、メッセージレベルの承認を行う能力もあります。 ただし、すべてのシミュレーションはクライアント上で行われます。 --サーバーサイドでシミュレーションは一切ありません(物理等)-- サーバーは基本的にはメッセージバスで、クライアントがすべてのピアにブロードキャストする前に、僅かなメッセージの変更と承認を行う際に使用されます。 オブジェクトに対する所有権や、ピア間でのゲーム内エクスペリエンスを調整するその他の付随的な懸念事項はすべて、クライアントプロトコルの実装に基づいています。

永続的な状態を保つために、突拍子もない事は一切しません。 reticulumの背後にpostgresqlデータベースがあり、耐久性のストレージ用の２つのメソッドのためのファイルストアがあります。 Reticulumは両方を管理しています、パーラメントルーム状態、オブジェクトのピン等を更新すると、それらの２つのバッキングストアの僅かな更新のためにReticulum内のAPIに接続する事になります。

私たちのネットワーキングのシリアル化は、その、お恥ずかしながら... JSONです。 （そして、少々驚きな事ではありますが、実務に使えてます）

すべてのアセットはファイルストアにバッキングされ、使い捨てキーで暗号化されます。 ファイルは、キャッシュ用にCDNが前にあるReticulumを介して提供されます。

ちなみに、ファイルシステムにはEFS on AWSを使用していますが、このアプローチは、サービスとAWSサービスを結合しないという点で優れています。 現在、比較的AWSに緊密に連携しているものが1つだけあります。新しいスクリーンショットサービスはlambdaであり、任意のWeb URLをハブに貼り付けるときにサムネイルを生成するために使用されます。 また、すべてのops terraformスクリプトはAWSベースですが、コード自体は（たとえば）AWSサービスを実行する必要がなく、AWS認証情報を渡す場所もありません。

わたしたしは全てのクライアントで「実際の」物理シミュレーションを実行しており、クライアント間との主な違いは、どのクライアントがどのポイントで、与えられたオブジェクトをシミュレートしているのかとそのオブジェクトからのメッセージの受信を担当するかの違いです。

所有者に収斂( convergence )することが保証されている基本的な「所有権移転」アルゴリズムがあります（バグがあれば修正します:)）。競合 ( conflict ) が発生するわずかな時間がありますが、最終的に所有者 ( owner ) は収斂します。したがって、ある与えらえたオブジェクトに対して、ゲームの状態 ( game state) はすべてのクライアントに収斂するはずです。

しかし、私達のネットワークの実装は典型的なFPSや非常に繊細なゲームメカニクスのようなユースケースに向けて設計されているわけではありません。 --それにしても、誰かが基本的な"ゲーム"をHubsで動作するようになっても、私は驚きせんよ、ただ、それが競技的なものであることを望まないでしょう 😃 例えば、私達のクライアントは敵対的ではなく（一般的には）お互いを信頼しております-- 私たちのユースケースとしては前提として、よほどな事がない限りは既に信頼できるピアたちと（ハッキングされた故障モードのクライアントで悪用を試みている場合は、キックする等して対応する予知がある）ルームリンクを交互に共有しているものだと想定しています。一方、典型的なゲームでは、ハッキングされたクライアントは、他のプレイヤーと同じ様に見えるように偽装されていることがあり、他のプレイヤーよりもアドバンテージを持っているなどの事があります。Hubsなどには[ゲームの優位性]の概念がないため、そういった事の対策を想定していません。