Regiony
Ta strona zawiera listę aktualnie dostępnych regionów do użycia z usługą Azure Remote Rendering.
Tabela regionów
Nazwisko | Region | URL |
---|---|---|
Australia Wschodnia | australiaeast | https://remoterendering.australiaeast.mixedreality.azure.com |
East US | eastus | https://remoterendering.eastus.mixedreality.azure.com |
Wschodnie stany USA 2 | eastus2 | https://remoterendering.eastus2.mixedreality.azure.com |
Japonia Wschodnia | japaneast | https://remoterendering.japaneast.mixedreality.azure.com |
Europa Północna | northeurope | https://remoterendering.northeurope.mixedreality.azure.com |
South Central US | southcentralus | https://remoterendering.southcentralus.mixedreality.azure.com |
Southeast Asia | southeastasia | https://remoterendering.southeastasia.mixedreality.azure.com |
Południowe Zjednoczone Królestwo | uksouth | https://remoterendering.uksouth.mixedreality.azure.com |
West Europe | westeurope | https://remoterendering.westeurope.mixedreality.azure.com |
Zachodnie stany USA 2 | westus2 | https://remoterendering.westus2.mixedreality.azure.com |
Najlepsze rozwiązanie dotyczące połączenia między regionami
Aby uzyskać najlepsze wyniki, aplikacja kliencka powinna zawsze używać regionu znajdującego się najbliżej lokalizacji fizycznej. W rozdziale wymagań dotyczących sieci omówiono strategie mierzenia opóźnień dla poszczególnych regionów. Interfejs API tworzenia sesji nie jest niejawnie wraca do innego regionu, gdy tworzenie zakończy się niepowodzeniem. Aby aplikacje klienckie były odporne na potencjalne awarie w określonych regionach, zaleca się dodanie co najmniej jednego rezerwowego regionu do logiki tworzenia sesji. Jeśli więc nie można przydzielić sesji, a interfejs API zwróci limit czasu, klient może wypróbować następny najbliższy region.
Następne kroki
- Wymagania dotyczące sieci