Ich versuche, den besten Weg zu finden, zufällige Matches in einem einfachen Spiel zu machen.
Beim Experimentieren mit NetStreams mit Adobe Cirrus kann ich direkt Verbindungen herstellen, Daten, Text, Video, Ton senden, alles mit Cirrus, was großartig ist. Ich finde es ziemlich einfach, eine einfache P2P-Verbindung zu bekommen, und es funktioniert genau so, wie ich es brauche.
Aber ich möchte wirklich eine zufällige Matchmaking-Funktion mit NUR Cirrus implementieren, so ist alles, obwohl p2p ...
Wie würde ich einen zufälligen Peer in der gleichen Gruppe anfassen ... das ist noch nicht in direkter Verbindung mit jemand anderem?
einige Ideen:
- Ich dachte, ich könnte vielleicht die Objektreplikation verwenden ... und wenn sich jemand mit dem GroupSpecifier verbindet, könnte ich dann ein anderes Objekt in dieses Shared-Array mit der lokalen peerID und deren Status schieben. dann könnte ich einfach das Array ändern, wenn sie in einem Spiel sind. Aber dann bin ich besorgt, es gibt keine Garantie, dass ihr Eintrag entfernt wird, wenn die Person das Webfenster gerade schließt.
- Ich dachte auch daran, einfach einen "Post" zu der Gruppe zu machen, die die nearID enthält, und andere Peers können den Post bekommen ... und diejenigen, die nicht in einem Spiel sind, werden versuchen, die Verbindung wiederherzustellen. Dann wird sich diese Seite mit ihnen verbinden. also sind sie beide in direkter Verbindung miteinander. Aber dann habe ich das Gefühl, wenn potentiell 100 Leute, die "verfügbar" sind ... den Beitrag bekommen ... dann versuchen sie alle und verbinden sich mit einer Person, dann könnte es Probleme verursachen.
- Ich dachte auch darüber nach, sendToNearest zu machen ... aber wäre das nicht der beste Weg, Leute zusammen zu bringen ... weil du nur so viele Nachbarn haben kannst, denke ich ... wenn es 1000 Leute in der Gruppe gäbe . du bist nur in der Lage, dich mit ein paar Gleichaltrigen zu verbinden, die deinen Nächsten für richtig halten? Dann könnte man im Grunde nur mit den gleichen 5-10 Leuten zusammentreffen oder aber technisch gesehen als Nachbarn betrachtet werden.
Ich glaube nicht, dass es eine Möglichkeit gibt, Timeouts und Wiederholungen zu vermeiden, wenn 1) die Netzwerklatenz unbekannt und variabel ist und 2) sich zu unbekannten Zeiten verbinden und verlassen können.
Daher muss jeder Knoten, der versucht, sich mit einem anderen Knoten zu verbinden, die folgenden statusbehafteten Parameter beibehalten:
Er muss eingehende Übereinstimmungsanforderungen ablehnen, wenn eine der ersten beiden wahr ist (es sei denn, die eingehende Anforderung stammt von Knoten X und ich habe eine ausstehende Anforderung an denselben Knoten). Es kann nur eine Übereinstimmung anfordern, wenn beide falsch sind.
Außerdem müssen sie nach der Abstimmung möglicherweise ihren Partner abfragen oder nach Verbindungsunterbrechungsmeldungen Ausschau halten und entsprechend reagieren (in die passende Phase zurückkehren oder beenden, was immer die Anwendung erfordert).
In diesem Fall können Sie zumindest den für die Synchronisierung der Knoten erforderlichen Netzwerkverkehr reduzieren, indem Sie einen Sortieralgorithmus erstellen, mit dem alle Knoten im Voraus wissen, wer ihre besten Übereinstimmungen sind, und versuchen, direkt eine Verbindung herzustellen passt zu einem Minimum an Netzwerkverkehr (keine Broadcast-Postnachrichten, keine zufälligen Versuche).
Der Schlüssel dazu wäre peerID, den jeder Knoten in einer NetGroup automatisch bekommt. Wenn ein Knoten eine NeighborConnect-Nachricht empfängt, enthält er auch eine eindeutige PeerID des Nachbarknotens. Mit anderen Worten, jeder Knoten hat einen eindeutigen Namen (der zufällig eine große Zufallszahl ist) und kennt die eindeutigen Namen aller anderen Knoten.
Diese PeerID ist lang, etwa 256 Bit. Sie können damit eine Sortierreihenfolge erstellen - etwa wie folgt: Betrachten Sie die ersten 32-Bit als int, XOR die PeerID des fernen Knotens mit Ihrer eigenen peerID und sortieren Sie die fernen Knoten vom niedrigsten zum höchsten.
Nun hat also jeder Knoten ungefähr die gleiche Vorstellung davon, mit wem er sich verbinden wird (auch wenn es Unterschiede geben wird, zum Beispiel basierend auf Un- / Verbindungsnachrichten, die sich durch die Gruppe ausbreiten). Knoten würden die sortierte Liste durchqueren und versuchen, eine Verbindung zu ihren besten Übereinstimmungen herzustellen, wahrscheinlich mit einer zufälligen Zeitüberschreitung zwischen fehlgeschlagenen Verbindungsversuchen.
Dies ist wahrscheinlich nicht die ideale Lösung - es gibt wahrscheinlich eine bessere, aber ich denke, es ist besser, als Knoten zufällig zu versuchen oder Broadcast-Nachrichten zu verwenden.
Tags und Links flash actionscript-3 flex flash-media-server rtmfp