Hasta aquí la configuración era un servidor WebSockets nodejs y un cliente WebSocket web js.
PRUEBA 2 (EN PROCESO)
Servidor dedicado autoritativo WebSockets Unity3D Linux con clientes html5 JS y clientes unity3D Windows, webGL, Android y editor.
He tenido un contratiempo de noob... el float.Parse de C# usa coma o punto en función del idioma/ajustes de la máquina donde se ejecute... como consecuencia el cliente no funcionaba en webGL y Android.
Lo he solucionado tirando de JsonUtility para serializar aunque lo revisaré más adelante para ver el impacto de rendimiento que conlleva porque va ubicado en "zona crítica".
#34 Tio estoy esperando que nos hagas un tutorial básico de como montar una arquitectura básica de multiplayer con sockets! Super interesante el topic
#35 tengo experiencia con unos cuantos backends de terceros, el más cómodo para mí es el de photon, tanto el cloud como el server dedicado, usaré sus conceptos, eso me permite tener claro lo que quiero hacer y como hacerlo.
#36 para no liarte con los sockets hay librerías de sobra... ¿has intentado hacer algo, hasta donde has llegado?
#37 Estoy intentando hacer un servidor en c# con sockets, he partido de aquí:
En el lado del cliente uso c++ para hacer un mini juego chorra de coches que lo único que necesito traquear por el momento es su posición y rotación, usando la librería de SFML que a parte del tema de dibujar gráficos también trae incluido sockets.
Hasta ahora he conseguido mandar desde el cliente la posición y la rotación en un buffer de bytes y luego en el servidor convertir los bytes otra vez en la información que quiero. Hasta ahí bien, por ahora consigo mandar la información, lo que no tengo muy claro es como organizar la arquitectura de clases y eso, es decir como organizar y que hacer con esa información. Lo siguiente que quiero intentar hacer es que el cliente no envíe la posicion sino la tecla que está pulsando, y el servidor calcule la nueva posición y sea este el que se lo envíe.
Estas vacaciones navideñas me tocará pelearme con este proyecto, es la primera vez que intento hacer algo multiplayer online y está guay e interesante pero a mi me resulta muy chungo... para debugear código y todo 
He visto un asset en la store con soporte webRTC...
Me parece interesante hacer un híbrido websockets + webRTC, esto dejaría fuera a Explorer por falta de soporte pero es algo con lo que se puede vivir xD
Problema... no lo detecté en el primer test del juego de las cajas porque tanto ws de node como los navegadores van por defecto con TCP_NODELAY activado, algo que websocket sharp no hace y está haciendo de lastre.
En los primeros test que he hecho con "webRTC data channel" (SCTP sobre UDP), mejora la latencia casi a la mitad respecto a websockets (estos con TCP_NODELAY), en las condiciones que he probado, es decir, un mierdi vps italia.
El problema con webRTC (a parte de complejidad, que no importa si la recompensa es buena) es que montar un servidor dedicado escala "malamente".
Así que ahora cambio de foco, dejo por un período el hilo y posible desarrollo del arena3 y me centraré 100% en lograr webRTC server escalable (sino super al menos decente) o algún hack equivalente.
Las soluciones en NPM son muy hacky. Deberías probar con un cliente puro https://github.com/pions/webrtc
Ejemplo de data-channels: https://github.com/pions/webrtc/tree/master/examples/data-channels
Lo que tengo en mente es usar webRTC en un proyecto multiplataforma...
Node y navegador ya lo tengo encaminado.
Ahora estoy con c++, y me vendría de perlas también c#.
Cuando tenga todo "testado" veré como monto la infraestructura... serán conexiones entre plataformas diferentes, ejecutable Windows, app Android, navegador...
Yo sinceramente te recomendaría que usaras WebRTC solo cuando sea imprescindible (en el navegador). En el resto de plataformas tienes acceso a comunicación vía UDP sin liadas por enmedio. Para el navegador, monta un gateway ligero que adapte tu comunicación UDP raw a WebRTC DataChannels.
Sino WebRTC te va a dar mucho por culo, más de lo que te va a ayudar. Además de que tu la única funcionalidad que quieres de WebRTC es que puedes usar UDP en el navegador.
Mi infraestructura (aún por definir) podría usar un servidor central dedicado con la física y demás lógica que será el master, autoritativo que comunicará con cada cliente.
Pero también me interesa a su vez conectar a todos los clientes entre ellos sin pasar por el servidor central.
Meterle ahí un gateway para una conexión directa navegador web vs app android aportaría tal latencia que no me rentaría el udp.
Por eso intento implementar WebRTC fuera del navegador... y sí, la liada va a ser de campeonato.
Pero si tira me compensa ^^
edit: el server será también multiplataforma...
Dejo un enlace interesante sobre el tema WebRtc.NET: WebRTC for C# & C++/CLI https://github.com/radioman/WebRtc.NET
AshNet... un poco de luz https://arena3.pro/data/info010.pdf (leer entero, tiene errores pero es interesante)
Investigando https://github.com/HumbleNet/HumbleNet (lleva tiempo sin actualizar)
HumbleNet is a cross platform networking library that utilizes WebRTC and WebSockets to handle network communication.Bueno, al final utilizaré HumbleNet...
Señalización es el mecanismo por el cual los pares se envían mensajes de control entre sí con el propósito de establecer el protocolo, canal, y método de comunicación.El servidor de señalización de HumbleNet lo tengo listo en c++ probado en windows y linux.
HumbleNet tiene una demo que funciona en Unity 5.6 que porta a Windows, Linux, Android, webgl sin errores y permite hacer conexiones directas cruzadas entre ellas, ej. webgl vs android.
enlace https://github.com/HumbleNet/WebGLRoller
El plugin que usa HumbleNet para webgl no funciona en las versiones superiores a 5.6, el proyecto lleva 2 años sin actualizar así que he tenido que solucionarlo por mi cuenta (emscripten WebAssembly).
Pero bueno, he conseguido repararlo y ya es funcional en Unity 2019 alpha...
Para empezar WebRTC tiene limitado el número máximo de conexiones vía navegador, en chrome son algo más de 200.
Intuyo que no es óptimo más de 50 o 100 usuarios si se emplea una topología de red malla (full) que sería el método de menor latencia al no tener que pasar por el server.
Usar una red centralizada mejoraría algo el número de usuarios pero duplicaría la latencia... aún así mejoraría a websockets en latencia (no en usuarios, es víable miles de usuarios usando websockets).
Tenía en mente usar algo mixto pero ya veré, primero tengo que experimentar mucho para sacar conclusiones.
