Usar solo RTMFP para concordancia aleatoria (Adobe Cirrus)

Question

Estoy tratando de encontrar la mejor manera de hacer una coincidencia aleatoria en un juego simple.

Al experimentar con netStreams usando Adobe Cirrus, puedo configurar fácilmente las conexiones directas, enviar datos, texto, video, sonido, todo usando Cirrus, que es genial. Me resulta bastante fácil hacer funcionar una simple conexión P2P, y funciona como lo necesito.

Pero realmente quiero para implementar una función de emparejamiento aleatorio utilizando sólo cirrus así que todo es, sin embargo p2p ...

¿Cómo hago para agarrar un par al azar en el mismo grupo ... que no es de una forma directa conexión con alguien más ya?

algunas ideas:

-I estaba pensando que tal vez podría utilizar la replicación de objetos ... y cuando alguien se conecta a la GroupSpecifier, entonces yo podría empujar otro objeto dentro de este conjunto compartido que tiene el peerID local y su estado . entonces podría simplemente alterar la matriz cuando estén en un juego. Pero estoy preocupado porque no hay garantía de que su entrada será eliminada si la persona simplemente cierra la ventana web.

- También pensé en simplemente hacer una "publicación" al grupo que contiene el nearID, y otros compañeros pueden obtener la publicación ... y aquellos que no están en un juego intentarán y dirigen la conexión de regreso. Entonces ese lado se conectará con ellos. entonces ambos estarán en conexiones directas entre ellos. Pero luego siento que si potencialmente cientos de personas están "disponibles" ... reciben el mensaje ... luego todos intentan conectarse con una persona, entonces podría causar problemas.

-Además, pensé en hacer sendToNearest ... pero no sería esa la mejor manera de unir personas ... porque solo puedes tener tantos vecinos, creo ... si hubiera 1000 personas en el grupo. solo podrás conectarte con unos pocos compañeros realmente considerados como tu vecino ¿no? Entonces, básicamente, podría terminar haciendo coincidir con las mismas 5-10 personas o, sin embargo, técnicamente se consideran vecinos.

Answer 1

No creo que haya ninguna forma de evitar tiempos de espera y reintentos cuando se hacen correspondencias de nodos dado que 1) existe una latencia de red desconocida y variable, y 2) las conexiones se pueden unir y abandonar en momentos desconocidos.

Así que cualquier nodo de intentar conectarse a otro nodo debe tener presente los siguientes parámetros con estado:

• estoy emparejado con otro nodo
• Tengo una petición destacado partido
  • Mi petición destacado partido es al nodo X

Se deben rechazar de entrada las solicitudes de coincidencia si cualquiera de las dos primeras es verdadera (a menos que la solicitud entrante provenga del nodo X, y tengo una solicitud pendiente para el mismo nodo). Solo puede solicitar una coincidencia si ambas son falsas.

Además, una vez emparejados, es posible que tengan que sondear a su compañero o mirar para desconectar los mensajes y responder adecuadamente (volver a la fase de coincidencia, o salir, sea lo que sea que la aplicación requiera).

En ese caso, puede al menos reducir la cantidad de tráfico de red necesaria para sincronizar los nodos creando un algoritmo de clasificación de modo que todos los nodos conozcan por adelantado quiénes son sus mejores coincidencias e intenten conectarse directamente a sus nodos. las mejores coincidencias con un mínimo de tráfico de red (sin mensajes de difusión, no intentos aleatorios).

La clave para esto sería peerID, que todos los nodos de un NetGroup obtienen automágicamente. Cuando un nodo recibe un mensaje NeighborConnect, también contiene un peerID único del nodo vecino. En otras palabras, cada nodo tiene un nombre único (que básicamente es un gran número aleatorio) y conoce los nombres únicos de todos los otros nodos.

Este peerID es largo, algo así como 256 bits. Puede crear un orden de clasificación con él, tal vez algo así como: considerando los primeros 32 bits como un int, XOR el nodo remoto peerID con su propio peerID, y clasifique los nodos remotos del más bajo al más alto.

Así que ahora cada nodo tiene aproximadamente la misma idea de con quién se van a conectar (aunque habrá diferencias, por ejemplo, basadas en mensajes de dis/conexión que se propagan a través del grupo). Los nodos atraviesan la lista ordenada intentando conectarse a sus mejores coincidencias, probablemente con un tiempo de espera aleatorio entre intentos fallidos de conexión.

Probablemente esta no sea la solución ideal, probablemente exista una mejor, pero me imagino que es mejor que intentar nodos al azar o usar mensajes de difusión.