server | v4 switch to v3  

Frequently Asked Questions

Contents

どのPhoton製品を使用するべきでしょうか?

対象となるゲームやプロジェクトの特性によって異なるため、これはむずかしい質問です。 ただし、弊社は以下のように推奨しています:

ご不明点な点がある場合、お問い合わせください。

Back To Top

Photon RealtimeとPUNのちがいは何ですか?

Photon Realtime wraps up all generic features needed for the load balancing of Photon. It is a product as much as a defined workflow to use Name Server, Master Server and Game Servers. Photon Realtime (a.k.a. LoadBalancing) is the basis for many games using Photon.

While Photon Realtime is independent from Unity, PUN adds many comfortable features for Unity and makes Realtime (the lower level) even easier to use.

これらの製品は同じバックエンド、サーバーアプリケーション、低いレベルの要素を共有しており、中核となるコンセプトも同一です。 当初、PUNはより優れたUNet(旧式のUnity Networking)と位置づけられていました:同様のAPIを保持し、さらに強固なバックエンドと豊富な機能を提供していました。 そして、その後PUNは次第に分化して、Unity上でのマルチプレイヤー向けNo1ソリューションとなりました。

Photon Realtime Unity SDKと比較して、PUNは以下のようなさらに高度なレベルの機能を提供し、またこれらの機能は購入後にすぐに使用できます:

  • Magic Unity コールバック
  • ネットワークオブジェクトをシリアル化および同期する外部Unityコンポーネント:もっとも重要なものにPhotonViewがあります
  • PunRPC
  • オフラインモード
  • ...

詳細はこちらを参照してください。

ただし、PUNはWebhookルームステートの保持をサポートしますが、保存されたゲームの画面を読み込む際に、シーン内のネットワークオブジェクトのステートを完全に復旧することはできません。 詳細は、こちらを参照してください。

Back To Top

LoadBalancing APIとPhoton Realtimeのちがいは何ですか?

LoadBalancing APIとPhoton Realtimeは、名称は異なりますがおなじものを指しています。 LoadBalancing APIまたはLoadBalancing Client APIは、Photon Realtime製品向けに弊社が提供している、クライアントSDK内で利用できるプログラミングインターフェースです。

Back To Top

Load Balancing

What Is The Maximum Number Of Players Supported By Photon Rooms?

The number of players is the main factor for increasing traffic inside the room. The more players there are the more messages are exchanged.

The short answer is:

4 is good, 8 is doable. Above 8 is tricky and requires some netcode magic.

The long answer is:

In theory, there is no limit. For more than 8 players you will need interest management. For massive amounts of players you would split them - your world - across multiple rooms.

Back To Top

Is There A Limit For Photon Strings?

Photon uses strings for lots of purposes: room name, lobby name, UserID, Nickname, custom property key, etc.

Photon binary protocol can serialize strings up to 32767 characters. For names and UserIDs 32 characters should be enough (e.g. a GUID is 32 characters). However, for custom properties keys, you should use shorter strings to minimize their overhead. This is especially important for properties that are visible in the lobby, as those are part of the room lists and get sent to everyone in the lobby, not just the couple of clients in a room.

Back To Top

Is There A Limit For The Number Of Custom Properties?

No. However, note that the more Custom Properties are set, the longer the clients load time will be because when joining the room, the clients also receive all of the properties. If you have too many of them and clients' load time exceed a certain amount of time, this might result in a disconnect for them.

Back To Top

Can I Send A Huge Message Using Photon?

We do not recommend transferring large data (i.e. files) using Photon unless you know what you are doing. We advise you to optimize the data you exchange and get in touch with us if you really have to send a very big message.

Photon Cloud has a server side limit for client buffers which is 500KB. So depending on the context a message could be considered:

  • "too big" for our per client buffer size on Photon Cloud > 500KB. If a client hits this limit in a short period of time, it will be disconnected by the server.
  • "too big" to be sent with UDP without resulting in an amount of fragments that might cause problems > 100KB.
  • "too big" to be sent without splitting it up into multiple UDP packets > 1.2KB (including protocols overhead).

For messages that get sent very regularly (10 times a second or even more often) we would recommend to keep their size below 1KB.

If a message only get sent rarely (for example once at the start of a match), then a size of multiple KB is still fine, but we still would recommend to keep it below 10KB.

In exceptional cases something like 20KB or even 50KB might make sense. But usually messages that big indicate that there is something wrong and you should review what you are doing and reconsider your options.

Back To Top

Which Data Should Be Sent Reliably And Which Should Be Sent Unreliably?

First of all, you should know reliability is an option only when the protocol used is UDP. TCP has its own "reliability" mechanism(s) which are not covered here.

Sending something reliable means that we should make sure it arrives to target(s). So in case we do not receive an acknowledgment after waiting enough time, we repeat sending until we receive the acknowledgment or we exceed the number of retrials. Also, repeating reliable events may cause extra latency and make subsequent events delayed.

Examples for not using reliability:

  • player position updates in realtime games
  • voice or video chat

Example for using reliability:

  • turn events in turn-based games

Back To Top

Why Do I Have So Many Disconnects In My Game?

The disconnects could be due to various reasons. We already have two documentation pages that can help you investigate the related issues:

Back To Top

How Messages Per Second Per Room Are Calculated?

Photon server counts total inbound and outbound messages every second and divide it by the total number of rooms (on the same Master Server).

Any operation request or operation response or event is considered a message. Photon operations return an optional operation response and trigger zero or more events. Cached events are also counted as messages.

Messages cost per in-room operation:

Operation Success: Best Case Success: Average Case Success: Worst Case
Create 2
(SuppressRoomEvents=true)
3
+ Join event (SuppressRoomEvents=false, default)
4
+ ErroInfo event (HasErrorInfo=true)
Join 2 + k
(SuppressRoomEvents=true)
+ k * cached custom event
2 + n + k
+ n * Join event (SuppressRoomEvents=false, default)
2 + 2 * n + k
+ n * ErroInfo event (HasErrorInfo=true)
Leave 2
(SuppressRoomEvents=true)
1 + n
+ (n - 1) * Leave event (SuppressRoomEvents=false, default)
2 + (n - 1) * 2
+ (n - 1) * ErroInfo event (HasErrorInfo=true)
RaiseEvent 1
(no operation response)
(target: interest group with no subscribers)
1 + n
+ n * custom event
(target: all/broadcast)
2 + 2 * n
+ n * ErroInfo event (HasErrorInfo=true)
+ Auth event (token refresh)
SetProperties 2
Broadcast=false
2 + n
+ n * PropertiesChanged event (Broadcast=true, default)
2 + 2 * n
+ n * ErrorInfo event (HasErrorInfo=true)

Back To Top

How Do I Calculate Traffic Consumed By A User?

This is a complex topic. First you need to know that any calculation done is just a theoretical estimation and may not reflect reality. We recommend building a Proof-of-Concept and use it to gather real data.

That being said here is how to estimate traffic generated by a single user inside a room:

Let's assume the following:

  • a room has N players.
  • a player sends F messages per second (message send rate in Hz)
  • average message size is X (in bytes, payload (P) + protocol overhead (O))
  • an average player spends H hours per month on your game

If we do not consider ACKs, connection handling (establishment, keep alive, etc.) commands and resends. Then we say that on average, a CCU consumes C (in bytes/month) in your game as follows:

C = X * F * N * H * 60 (minutes per hour) * 60 (seconds per minute)

Back To Top

切断後すぐに部屋に再び参加する方法は?

ルームへの参加中に予期しない切断から回復するために、クライアントはルームへの再接続と再参加を試みることができます。 これを「クイック再入室」と呼びます。 クイック再入室は、次の場合にのみ成功します:

  • ルームは同じサーバー上にまだ存在するか、読み込めます: プレイヤーが退室しても、他のプレイヤーがまだ参加している場合、後者はPhotonサーバー上で生き続けることができます。 プレイヤーが最後に退出し、ルームが空になった場合、EmptyRoomTTLは、プレイヤーが参加または再参加するのを待機している時間です。 EmptyRoomTTLの後、ルームがまだ空で、誰も参加していない場合、Photonサーバーから削除されます。 永続化条件が満たされ、Webhookがセットアップされている場合、ルームの状態を構成済みのWebサービスに保存して、後で読み込むことができます。
  • アクターは内部で非アクティブとしてマークされます。同じUserIdを持つアクターがアクターのリスト内に存在しますが、現在ルームに参加していません。 これには、PlayerTTLが0と異なる必要があります。
  • 非アクティブなアクターのPlayerTTLが期限切れになりませんでした。アクターが戻ってくるオプションを選択してルームを出ると、非アクティブ化タイムスタンプを保存します。 ルームが稼働している限り、非アクティブ化時間からPlayerTTLミリ秒が経過すると、それぞれのアクターがアクターのリストから削除されます。 それ以外の場合、アクターが再入室を試みるときに、再入室の試行時間と非アクティブ化時間のミリ秒単位の差がPlayerTTLを超えると、アクターはアクターのリストから削除され、再入室は失敗します。 そのため、非アクティブなアクターは、非アクティブ化時間の後、PlayerTTLミリ秒だけルームに再入室できます。

「クイック再入室」は2つのステップで構成されます。

  • Reconnect切断されたら、適切な接続メソッドを呼び出すだけです。
  • Rejoin: loadBalancingClient.OpRejoin(roomName)を呼びだす。

Back To Top

Self Hosting

Can I Run Photon Server On Linux?

No. Photon Server is Windows only. Read the "Requirements" for more details.

Back To Top

How To Host Photon Server On Amazon?

Steps to host Photon Server on Amazon:

  1. Setup a new Windows Server EC2 instance

    • Create Amazon Web Services account.
    • Sign in to AWS portal.
    • Go to "Service -> EC2".
    • Click "Launch Instance" under "Create Instance" section.
    • Choose a Microsoft Windows Server edition supported by Photon Server by hitting the corresponding "Select" button.
    • "Choose an Instance Type" then jump to "6. Configure Security Group"
    • Create a new security group "Photon Server" to allow incoming ports as shown in this page.
    • Click "Review and Launch" then review and "Launch".
    • Create or select an existing key pair.
    • Tick the acknowledgment toggle and hit "Launch Instances".
    • Click "View Instances" and wait for instance to finish initialization.
  2. RDP Connect to new instance

    • Choose EC2 instance.
    • Click "Connect".
    • Click "Get Password".
    • Upload private key or copy its content then "Decrypt Password".
    • Get RDP shortcut by clicking "Download Remote Desktop File".
    • Connect to remote machine by double clicking the shortcut.
    • Enter your credentials and log in.
  3. Setup Photon Server SDK

    • Create a Photon account.
    • Download Photon Server SDK.
    • Extract package and copy files to remote machine.
    • Start Photon Control.
    • Install Photon as a service.
    • Start Photon service. Back To Top

      スレッド

単独のPhoton Serverでいくつのスレッドが実行されていますか?

スレッドの利用は以下のように分けられます:

  1. ネイティブ - 9個のスレッド
  2. 管理 - .Netデフォルト設定を使用する.Net ThreadPoolにもとづく。

この設定には非常に厳密にテストをおこなってきましたので、広範な負荷プロファイルに対して問題なく動作します。

管理スレッドの使用は、状況によって異なります(.Net Windows Performanceカウンターに記載されたとおりです):

a) 1個~12個まで:通常のPhoton Cloud Realtime負荷に対応 b) 35個以上:プラグイン間の通信(ロッキング)をともなうプラグインを実行するカスタマークラウドが例で、より高いコンテンションの原因となります(弊社のコードとは対照的です)。

備考:必要に応じて.Net ThreadPool設定は調整できます。 これまでデフォルトの設定で適切な成果が得られていますが、それぞれの状況に応じて調整が必要かもしれません。

Back To Top

レース状態やその他のマルチスレッドの問題を回避する方法は?

In Photon we did as much as possible to simplify things:

  1. 任意のスレッドからPhotonPeerメソッドを使用できます。
  2. PhotonPeerからのすべての通知は1つのファイバーで実行されます(以下のファイバーについて読んでください)。
  3. ルーム内のすべてのタスクは1つのファイバーで実行されます。
  4. ピアは、マルチスレッドの問題からデータを保護するために、ルームのファイバーにメッセージを送信します。

ファイバーは、FIFO方式で1つずつ順番に実行されるタスクのリストです。 これは、それらが1つのスレッドで実行されることを意味しません。 実際には、多くのスレッドで実行されますが、1つずつ実行されます。 したがって、最初のタスクはスレッドAで実行され、終了すると、2番目のタスクはスレッドBで実行されます。 ただし、特定の瞬間に1つのスレッドだけがルームデータにアクセスします。 多くのファイバーが同じデータにアクセスする場合、ロックを使用します。 たとえば、ルームのキャッシュ内:

次のようにファイバーを使用できます:

// ルームコンストラクタ
someFiber = new PoolFiber(); // 新しいファイバーを作成
someFiber.Start();
someFiber.ScheduleForInterval(someRepetitiveRoutine, 0, 100); // すぐに開始し、100ミリ秒ごとに繰り返します(1秒間に10回)。 このパラメータは、ファイバにロジックを
// 追加する必要がある他のポイントで異なる場合があります
someFiber.Enqueue(newTask);
someFiber.Enqueue(()=>{ anotherTask(parameters);});
// タスクから、ルームにメッセージを送信できます。 例:タスクの結果をルームに通知する場合
room.EnqueueMessage(new YourCustomMessage(somethingToSend));

同じコードまたは同じデータを共有する複数のカスタムファイバーを使用する場合、異なるファイバーのアクションが同時に実行されるため、アクセスを同期する必要があることに注意してください。

Back To Top

ログの記録

クライアントが接続または切断する度にログエントリーを書く方法は?

アプリケーションのlog4net.configに以下を追加してください:


<logger name="Photon.SocketServer.ApplicationBase">
    <level value="DEBUG"/>
</logger>

「{MyApplication}.log」からの出力:

正常な接続:

2013-05-02 11:19:02,506 [23] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnInit - ConnID=17, IP 127.0.0.1 on port 4530
2013-05-02 11:19:02,506 [23] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnInit - response sent to ConnId 17 with SendResult Ok

切断:

2013-05-02 11:19:07,608 [24] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnDisconnect - ConnID=17

Back To Top

Photonがクライアントに作業レスポンスを送信する際にログエントリーを書く方法は?

アプリケーションの「log4net.config」に以下を追加してください:


<logger name="Photon.SocketServer.PeerBase">
    <level value="DEBUG"/>
</logger>

「{MyApplication}.log」からの出力:

2013-05-02 11:19:02,569 [21] DEBUG Photon.SocketServer.PeerBase [(null)] - SentOpResponse: ConnID=17, opCode=255, return=0, ChannelId=0 result=Ok size=14 bytes

Back To Top

Photonがクライアントから作業リクエストを受信した際にログエントリーを書く方法は?

この様なログは、アプリケーションのPeerクラス(HivePeerから継承します)でおこなうのが最適です。


<logger name="Photon.Hive.HivePeer">
    <level value="DEBUG"/>
</logger>

「{MyApplication}.log」からの出力:

2013-05-02 11:19:02,553 [21] DEBUG Photon.Hive.HivePeer [(null)] - OnOperationRequest. Code=255

OnOperationRequestメソッドで、ログエントリーの内容を修正可能です。

protected override void OnOperationRequest(OperationRequest operationRequest, SendParameters sendParameters)
{
    if (log.IsDebugEnabled)
    {
        log.DebugFormat("OnOperationRequest. Code={0}", operationRequest.OperationCode);
    }
    // snip
}

Back To Top

クライアントが切断する理由は?タイムアウトのデバッグ方法は?

クライアントが切断する理由を確認するには、ピアでOnDisconnectが呼び出された場合のデバッグログエントリーを書くようにしてください。


<logger name="Photon.Hive.HivePeer">
    <level value="DEBUG"/>
</logger>

ピアクラス(HivePeerから継承します)では、OnDisconnect()メソッドは以下のようになります:

protected override void OnDisconnect(DisconnectReason reasonCode, string reasonDetail)
{
    if (log.IsDebugEnabled)
    {
        log.DebugFormat("OnDisconnect: conId={0}, reason={1}, reasonDetail={2}", this.ConnectionId, reasonCode, reasonDetail);
    }
    //     
}

「{MyApplication}.log」からの出力:

2013-05-02 11:19:07,639 [12] DEBUG Photon.Hive.HivePeer [(null)] - OnDisconnect: conId=17, reason=ClientDisconnect, reasonDetail=

UDPを使用している場合:「TimeoutDisconnect」の際は、以下のように「reasonDetail」にRoundTripTime履歴が含まれます。

index - sequence - rtt - variance - sentTime - recvTime - cmd_rtt

0 - 326 - 0 - 0 - 830717056 - 830728351 - 11295
1 - 325 - 89 - 19 - 830715918 - 830716042 - 124
2 - 324 - 85 - 14 - 830714826 - 830714904 - 78
3 - 323 - 86 - 17 - 830712751 - 830712813 - 62
4 - 322 - 89 - 14 - 830711659 - 830711737 - 78
5 - 321 - 90 - 16 - 830710551 - 830710645 - 94
6 - 320 - 90 - 19 - 830709428 - 830709537 - 109
7 - 319 - 88 - 19 - 830708320 - 830708414 - 94
8 - 318 - 88 - 23 - 830707197 - 830707306 - 109
9 - 317 - 86 - 24 - 830706105 - 830706183 - 78
10 - 316 - 87 - 29 - 830704701 - 830704763 - 62
... etc ...

各行は以下の値から成ります: 

  • Index -(0から49の範囲の値をとり、0は最新で49は最も古いです。直近の50個のエントリーのみが表示されます。)
  • Sequence - 増加するシーケンス番号
  • rtt (RoundTripTime - 最新のRTT、ミリ秒単位 - ACKの処理後、またはタイムアウトの発生後から利用可能です)
  • variance (最新の偏差、ミリ秒単位) 
  • sentTime (コマンドが送信された時刻)
  • recvTime (ACKが受信された時刻) 
  • cmd_rtt ( コマンドが送信されてからACKを受信するまでのタイムスパン、ミリ秒単位)

上記の例では、クライアントのcmd_rttは62ミリ秒から124ミリ秒でした。最後のコマンドに対してACKを受信しなかった後、11秒間にわたって切断しました。

Back To Top

Billing

Do You Have Special Offers For Students, Hobbyists Or Indies?

All our products have a free tier and a one-off entry-plan. We also usually take part in Unity's asset store sales and occasionally give vouchers to lucky ones.

Back To Top

Can I Combine More Than One 100 CCU Plan For A Single Photon Application?

No. The 100 CCU plans are not stackable and can be applied only once per AppId. If you purchase multiple PUN+ asset seats then you must redeem each 100 free CCU for a separate AppId. If you need more CCU for a single app, the next higher plan is the 500 CCU one. If you subscribe to a monthly or yearly plan, then you will still keep the 100 CCUs for 60 months on top of / in addition to the CCU from your monthly/yearly plan.

ドキュメントのトップへ戻る