QoS Measurements with P2P via PlayFab Party

Question

question

Alberto Corona asked Aug 3, '20

QoS Measurements with P2P via PlayFab Party

I'm looking for clarification on how PartyManager::GetRegions works with P2P connections not using PlayFab servers. The documentation does not quite clarify on whether there is any differentiation in how QoS is measured in different use cases of PlayFab Party. Is it safe to assume that the method of which QoS is measured does not change between PlayFab Party use cases? Getting a few more details about how QoS measurements works with Party would help me ensure there are no regressions in our current work to move to PlayFab Party in terms of ensuring that QoS is correctly/adequately measured between clients

documentation

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2020-08-04T09:21:30Z

Seth Du answered Aug 4, '20

May I ask what do you mean by “different use cases”? Can you share more details with us?

The Party will always involve PlayFab (Azure) servers, because there are hosted relay servers on Azure to help improve the P2P connections. By default, Party Network may automatically select the region with the lowest latency so that the P2P connections are optimized within Azure.

According to the documentation, the QoS will be measured when Party is initialized, but only after PartyRegionsChangedStateChange reports success, QoS can be retrieved. PartyManager::GetRegion is for retrieving this information so that you may manually select preferred region according to your specific criteria.

2

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Alberto Corona commented · Aug 04, 2020 at 02:09 PM

Apologies, I had some mixup between Party and PlayFab itself when referring to use cases.I seem to keep thinking of Party as a subset of PlayFab.

As you mention, Party Network will automatically select the region with the best QoS. In that case then PartyManager::GetRegions is only meant for retrieving QoS details and not necessarily for selection of the region with the best QoS for the client, even though the functionality to do so is present?

0 ·

Seth Du ♦ Alberto Corona commented · Aug 05, 2020 at 02:46 AM

No, it is not necessary, but you can still implement it anyway. What I have mentioned is that if there are no specific requirements, directly initializing Party network will be fine because it already selects the best QoS. However, there can be different criteria for developers to select regions. For example, Party will charge differently in different zones, sometimes we may choose between price and latency.

0 ·

question