Używanie tylko RTMFP do losowego dopasowywania (Adobe Cirrus)

Question

Próbuję wymyślić najlepszy sposób robienia losowych dopasowań w prostej grze.

Eksperymentując z netStream za pomocą Adobe Cirrus, mogę łatwo skonfigurować bezpośrednie połączenia, przesyłać dane, tekst, wideo, dźwięk za pomocą Cirrus, który jest świetny. Łatwo jest uzyskać proste połączenie P2P i działa tak, jak tego potrzebuję.

Ale naprawdę chcę zaimplementować funkcję losową kojarzeń używając wyłącznie cirrus więc wszystko jest jakby p2p ...

Jak bym go o chwytając losową sobie równych w tej samej grupie ... to nie jest w bezpośrednim połączenie z kimś innym już?

kilka pomysłów:

-I myślał mógłbym użyć obiektu replikację ... a gdy ktoś łączy się z GroupSpecifier mogłem następnie wcisnąć inny obiekt w tej wspólnej tablicy, która ma lokalną peerID i ich status . wtedy mógłbym zmienić tablicę, gdy są w grze. Ale potem martwię się, że nie ma gwarancji, że ich wpis zostanie usunięty, jeśli osoba po prostu zamknie okno sieci.

- Myślałem także o tym, że po prostu robię "wpis" do grupy zawierającej identyfikator bliskiID, a inni użytkownicy mogą uzyskać wpis ... a te, których nie ma w grze, spróbują nawiązać połączenie. Wtedy ta strona połączy się z nimi. tak więc oba są w bezpośrednim połączeniu ze sobą. Ale wtedy mam ochotę, jeśli potencjalnie 100 ludzi, którzy są "dostępni" ... otrzymają pocztę ... wtedy wszyscy spróbują połączyć się z jedną osobą, wtedy może to spowodować problemy.

-Also, myślałem o zrobieniu sendToNearest ... ale nie byłby to najlepszy sposób na dopasowanie ludzi ... ponieważ możesz mieć tylko tylu sąsiadów, myślę, że ... gdyby było 1000 osób Grupa. będziesz w stanie połączyć się tylko z kilkoma rówieśnikami uważanymi za twoich sąsiadów? Wtedy w zasadzie może się skończyć po prostu z tymi samymi 5-10 osobami lub technicznie uważanymi za sąsiadów.

Answer 1

Nie sądzę, że jest jakiś sposób na uniknięcie limitów czasu i ponownych prób przy dopasowywaniu węzłów, ponieważ 1) istnieje nieznana i zmienna opóźnienie sieci, oraz 2) połączenia mogą się łączyć i wychodzić w nieznanym czasie.

Więc każdy węzeł próbuje połączyć się z innym węźle należy zachować następujące parametry stanowe:

• mam dopasowane innego węzła
• mam prośbę mecz wyjątkową
  • zaległe żądanie mecz jest do węzła X

To musi odrzucić przychodzące żądania dopasowania, jeśli jedna z dwóch pierwszych jest prawdą (chyba że żądanie przychodzące pochodzi z węzła X, a ja mam zaległe żądanie do tego samego węzła). Może zażądać tylko dopasowania, jeśli oba są fałszywe.

Ponadto, po dopasowaniu, mogą potrzebować odpytać partnera lub obejrzeć, czy nie rozłączają wiadomości i odpowiednio reagować (wrócić do fazy dopasowywania lub wyjść, niezależnie od wymaganej aplikacji).

W tym przypadku można przynajmniej zmniejszyć ruch sieciowy wymagany do synchronizacji węzłów, tworząc algorytm sortowania, tak aby wszystkie węzły znały z wyprzedzeniem, kto najlepiej pasował, i próbowały nawiązać bezpośrednie połączenie z ich węzłami. najlepsze dopasowania z minimalnym ruchem sieciowym (bez wiadomości postów, bez prób losowych).

Kluczem do tego będzie peerID, który automatycznie dostaje każdy węzeł w grupie NetGroup. Gdy węzeł otrzymuje komunikat NeighborConnect, zawiera również unikalny identyfikator peerID węzła sąsiada. Innymi słowy, każdy węzeł ma unikalną nazwę (która w zasadzie jest dużą liczbą losową) i zna unikalne nazwy wszystkich innych węzłów.

Identyfikator peerID jest długi, podobny do 256-bitów. Możesz utworzyć przy tym kolejność sortowania - być może coś w stylu: biorąc pod uwagę pierwsze 32-bity jako int, XOR - peerID zdalnego węzła z własnym identyfikatorem peerID i sortuj węzły zdalne od najniższego do najwyższego.

Teraz każdy węzeł ma mniej więcej tę samą koncepcję tego, z kim ma się połączyć (nawet jeśli będą różnice, na przykład na podstawie komunikatów dis/connection propagujących w grupie). Węzły będą przechodzić przez posortowaną listę, próbując połączyć się z najlepszymi odpowiednikami, prawdopodobnie z pewnym losowym czasem między nieudanymi próbami połączenia.

Prawdopodobnie nie jest to idealne rozwiązanie - prawdopodobnie istnieje lepszy, ale wyobrażam sobie, że to lepsze rozwiązanie niż próbowanie węzłów losowo lub używanie wiadomości rozgłoszeniowych.