Degradacja matchmakingu po wyjściu Operacji Grim Sky

4 września 2018, zaktualizowaliśmy ogólnodostępne serwery do wersji Operacja Grim Sky. Aktualizacja Grim Sky wprowadziła poprawki do przebiegu matchmakingu z myślą o usprawnieniu procesu wstępnego wyboru serwera gry. Po jej wdrożeniu, zauważyliśmy wzrost liczby generowanych błędów w matchmakingu w porównaniu do fazy serwera testowego. Gracze, głównie w Ameryce Północnej nie byli w stanie połączyć się z grą przy pomocy matchmakingu.

Poniżej podsumowujemy, co się zdarzyło i jakie kroki podjęliśmy, żeby rozwiązać problem.

Proces matchmakingu

Wybranie któregokolwiek z trybów online za pomocą przycisku “Tryb wieloosobowy” rozpoczyna dwuetapowy proces.

Najpierw, gra łączy się z naszymi usługami matchmakingu, szukając najodpowiedniejszego meczu. Ten krok, w zależności od trybu gry, waszej rangi i liczby osób grających w danym momencie trwa zwykle od 10 do 60 sekund (degradacja nie dotyczy tego etapu procesu).

Następnie, klient gry próbuje połączyć się z serwerem rozgrywki. To jest moment, w którym występuje degradacja.

Połączenia z serwerami naszej gry to wymiana wiadomości UDP (User Datagram Protocol – protokół pakietów użytkownika) pomiędzy klientem i serwerem. Z perspektywy wysokiego poziomu kodu wygląda to następująco:

Klient negocjuje kanał komunikacji z serwerem, czeka na odświeżenie klatki (~16ms) a następnie wysyła informację (pozdrowienie) na ten kanał.

Odkrycie

Badając problem, zauważyliśmy, że już wcześniej w połączeniu od strony serwera występował błąd: jeśli 4. wiadomość (pozdrowienie) dotrze do serwera przed 3. (Ack - potwierdzenie) w bardzo krótkim czasie, połączenie zakończy się statusem błędu i nie będzie mogło być przywrócone. W takiej sytuacji wystąpi błąd 6-0x00001000 (upłynięcie limitu czasu połączenia).

W większości przypadków, gdy wiadomości są wysyłane w określonej kolejności, są również otrzymywane w tej samej, konkretnej kolejności. Zmiana kolejności wiadomości zdarza się rzadko, ale warto zwrócić uwagę, że może nastąpić w uzasadnionych przypadkach – na przykład: w wyniku złej konfiguracji zapory sieciowej po stronie gracza, która utrudni śledzenie ruchu sieciowego. Mówiąc inaczej, mała liczba tego typu błędów nie jest niczym poważnym i niespodziewanym, ale nie można tego powiedzieć o olbrzymiej ilości i trzeba uznać taki stan za nieprawidłowy. Z tego powodu nie byliśmy w stanie zauważyć rozmiarów problemu w trakcie prób na serwerze testowym, ponieważ nie pozwalają na to rozmiary grupy uczestniczącej w testach.

Ewolucja degradacji

Jedną ze zmian, które wprowadziliśmy w Operacji Grim Sky, jest optymizacja sprawiająca, że klient nie czeka i wysyła 3. i 4. wiadomość od razu, wciąż jednak w kolejności, w bardzo krótkim przedziale czasu. U większości dostawców usług internetowych, nie wywołuje to żadnej zmiany. Jednak u niektórych wysyłanie dwóch wiadomości w tak krótkim czasie powoduje, że w większości przypadków ich kolejność ulegnie zmianie, co gwarantuje wystąpienie omawianego problemu u graczy korzystających z usług takiego dostawcy. Wynika to oferowanej przez dostawcę niskiej latencji łącza. W skrócie, im niższa latencja połączenia gracza, tym wyższe prawdopodobieństwo wystąpienia tego błędu.

Ponadto, jeśli choć jeden z członków drużyny nie może dołączyć do meczu, faza łączenia z serwerem gry u każdego zakończy się błędem (2-0x0000D012). W zamyśle miało to zapewnić spójność drużyn podczas matchmakingu, gdy jednak tak wielu graczy miało problem z omawianym wcześniej błędem, powodowało to lawinowy efekt u tych, którzy dołączali do gry razem z takim graczem.

Po zidentyfikowaniu i potwierdzeniu problemu, mogliśmy poprawić serwer gry, by ten problem nie mógł już nigdy wystąpić.

Ramy czasowe poprawki

Pierwszych kilka dni spędziliśmy, próbując odtworzyć błąd, zgodnie z naszym ówczesnym stanem wiedzy na temat tego typu sytuacji. Niestety, te wysiłki nie przynosiły rezultatu. Niezależnie od tego, ile różnych symulacji latencji, odchyleń sygnału (jitter) i utraty pakietów wypróbowaliśmy, nie byliśmy w stanie odtworzyć błędu tak, by mieć pewność, że znaleźliśmy jego prawdziwą przyczynę. Tracenie czasu i środków na próby “naprawienia” czegoś, co nie jest prawdziwą przyczyną problemu, przedłuża tylko jego trwanie, działając na szkodę naszą i graczy.

Na szczęście, wielu graczy wyciągnęło do nas pomocną dłoń. Pracowaliśmy wspólnie z kilkoma z tych, u których problem występował szczególnie często i dzięki ich wspaniałomyślności i współpracy, mogliśmy poczynić większe kroki w naszym śledztwie. Podczas drugiej sesji debugowania, byliśmy pewni, że odkryliśmy źródło problemu i że możemy rozpocząć prace nad właściwą poprawką. Do niedzielnego wieczoru ukończyliśmy jej pisanie i po przeprowadzeniu w poniedziałek wraz z grupą biorących udział w testach graczy-ochotników ostatecznej sesji debugowej, by upewnić się, że problem już nie występuje, czuliśmy, że znaleźliśmy rozwiązanie. Wprowadzenie poprawki zaplanowano od razu na następny dzień roboczy, wtorek.

Następne kroki

Jednym z problemów, z którymi przyszło nam się zmierzyć, kiedy próbowaliśmy ustalić przyczynę błędu, było to, że pojawił się on w tym samym czasie co duża aktualizacja sezonowa. Przez to nie mogliśmy przywrócić wcześniejszej wersji, bo oznaczałoby to cofnięcie premiery całego sezonu.

Na przyszłość, rozpoczęliśmy przygotowania do usprawnienia naszego procesu publikacji zmian, które pozwoli nam wypuszczać nową zawartość – w szczególności zawartość nowych sezonów – oddzielnie od zmian na niskim poziomie kodu, do których gracze nie mają bezpośredniego dostępu. Dzięki temu, jeśli podobne problemy kiedyś jeszcze wystąpią, będziemy mogli w razie potrzeby cofnąć aktualizację.

Korzystając z okazji, chcieliśmy jeszcze raz gorąco podziękować tym graczom, którzy poświęcili swój czas, by pomóc nam rozwiązać problem dla całej społeczności Rainbow Six. Jesteście niesamowici!

Ponadto, wciąż pracujemy nad przyczynami zawieszania się, z którymi mają problem gracze na wszystkich platformach. Dla większości z nich mamy już gotowe poprawki, które zostaną wprowadzone wraz z Aktualizacją 3.1.