Utilizzo di RTMFP solo per corrispondenza casuale (Adobe Cirrus)

Question

Sto cercando di trovare il modo migliore per eseguire una corrispondenza casuale in un gioco semplice.

Durante gli esperimenti con netStreams con Adobe Cirrus, posso facilmente impostare connessioni dirette, inviare dati, testo, video, suoni utilizzando Cirrus che è fantastico. Trovo abbastanza facile ottenere una semplice connessione P2P in corso, e funziona proprio come ne ho bisogno.

Ma ci tengo a implementare una funzione di matchmaking casuale usando SOLO Cirrus quindi tutto è però p2p ...

Come potrei fare per afferrare un peer casuale dello stesso gruppo ... che non è in una diretta connessione con qualcun altro già?

alcune idee:

-I stava pensando forse avrei potuto utilizzare la replica oggetto ... e quando qualcuno si collega al GroupSpecifier, ho potuto quindi spingere un altro oggetto in questo array condiviso che ha il peerID locale e il loro stato . quindi potrei semplicemente modificare l'array quando sono in una partita. Ma poi sono preoccupato che non vi è alcuna garanzia che il loro ingresso verrà rimosso se la persona si limita a chiudere la finestra web.

-Ho pensato anche a fare un "post" al gruppo che contiene il nearID, e gli altri peer possono ottenere il post ... e quelli che non sono in un gioco proveranno a ricollegarsi. Quindi quella parte si collegherà a loro. quindi saranno entrambi in connessione diretta l'uno con l'altro. Ma poi mi sento come se potenzialmente centinaia di persone "disponibili" ... prendessero il posto ... poi provano tutti a connettersi con una persona, quindi potrebbero causare problemi.

-Inoltre, ho pensato di fare sendToNearest ... ma non sarebbe il modo migliore per abbinare le persone ... perché puoi avere solo tanti vicini di casa penso ... se ci fossero 1000 persone nel gruppo. riuscirai a connetterti solo con qualcuno che in realtà considera il tuo vicino giusto? Quindi in pratica potresti finire per abbinarti alle stesse 5-10 persone o comunque tecnicamente considerate un vicino.

Answer 1

Non penso che ci sia modo di evitare timeout e tentativi durante la corrispondenza dei nodi dato che 1) c'è una latenza di rete sconosciuta e variabile, e 2) le connessioni possono unirsi e partire in orari sconosciuti.

Quindi qualsiasi nodo che tenta di connettersi a un altro nodo deve tenere i seguenti parametri stateful:

• sto abbinato con un altro nodo
• ho una richiesta partita eccezionale
  • Mia eccezionale richiesta partita è al nodo X

occorre respingere in arrivo verifica le richieste se uno dei primi due è vero (a meno che la richiesta in arrivo non provenga dal nodo X e io abbia una richiesta in sospeso per lo stesso nodo). Può richiedere una corrispondenza solo se entrambi sono falsi.

Inoltre, una volta abbinati, potrebbe essere necessario eseguire il polling del partner o controllare i messaggi di disconnessione e rispondere in modo appropriato (tornare alla fase di corrispondenza o uscire, qualunque sia l'applicazione necessaria).

Stando così le cose, si può almeno ridurre la quantità di traffico di rete necessario per sincronizzare i nodi con la creazione di un algoritmo di ordinamento in modo tale che tutti i nodi sapere in anticipo chi sono i loro migliori partite sono, e tentare di connettersi direttamente al loro le migliori corrispondenze con un minimo di traffico di rete (nessun messaggio di broadcast, nessun tentativo casuale).

La chiave per questo sarebbe peerID, che ottiene automaticamente ogni nodo in un NetGroup. Quando un nodo riceve un messaggio NeighborConnect, contiene anche un peerID univoco del nodo adiacente. In altre parole, ogni nodo ha un nome univoco (che in pratica è un grosso numero casuale) e conosce i nomi univoci di tutti gli altri nodi.

Questo peerID è lungo, qualcosa come 256 bit. È possibile creare un ordine di ordinamento con esso - forse qualcosa di simile: considerando i primi 32 bit come int, XOR il peerID del nodo remoto con il proprio peerID e ordina i nodi remoti dal più basso al più alto.

Così ora ogni nodo ha approssimativamente la stessa idea di chi si connetteranno (anche se ci saranno differenze, ad esempio, basate su messaggi di dis/connessione che si propagano attraverso il gruppo). I nodi attraverserebbero la lista ordinata cercando di connettersi alle loro migliori corrispondenze, probabilmente con un certo timeout casuale tra i tentativi di connessione falliti.

Probabilmente questa non è la soluzione ideale, probabilmente esiste una soluzione migliore, ma immagino sia meglio che cercare nodi casuali o utilizzare messaggi broadcast.