Empecemos por lo básico: hay protocolos de red. Algunos protocolos de red se ejecutan uno encima del otro. Puede consultar el modelo OSI: https://en.wikipedia.org/wiki/OSI_model
Por lo tanto, para la capa física (capa 1), la conexión puede ser cableada o inalámbrica, las especificaciones del tipo de cable o la frecuencia de radio pertenecen a esta capa. Desde el punto de vista del software, realmente no hablamos de la capa 1. En la práctica, hablamos de los protocolos de la capa 2. Por ejemplo, hablamos de Ethernet (capa 2), sin embargo, hay Ethernet rápida, Gigabit Ethernet, 100 gigabit Ethernet, etc ... esos son protocolos particulares de capa 1 que admiten Ethernet (capa 2). Algo similar sucede con Wi-Fi, 3G, Bluetooth, etc.
Eso no significa que podamos simplemente ignorar la primera capa. ¿Por qué? Bueno, porque cada protocolo de capa 1 tiene un rango. La señal solo puede ir tan lejos hasta que caiga por debajo del ruido y la interferencia. Los cables solo pueden ser tan largos, etc. Por esta razón, los protocolos tienen un área.
- Para las redes de área personal, tenemos cosas que no se conectan demasiado y que puede llevar con usted.
- Para las redes de área local, tenemos todo lo que puede configurar en un edificio.
- Para las redes de área metropolitana, tenemos los sistemas que utiliza el ISP para llegar a esos edificios.
- Para la red de área amplia, tenemos los cables que van de ciudad a ciudad o de país a país, a menudo pasando por debajo del océano ... y también el satélite que conecta grandes distancias.
Ninguno de ellos es "Internet", ya que es la red de redes, ninguna red única es Internet. Sin embargo, llamaremos "Internet" a todo lo que esté más allá de la LAN. ---
Es en la capa 2 donde se definen las direcciones "físicas" de MAC (control de acceso al medio). No deberíamos tener que preocuparnos por esto, porque no deberíamos estar trabajando a un nivel tan bajo para el juego.
Existe la posibilidad de que eso sea suficiente. Por ejemplo, el emparejamiento de Bluetooth podría funcionar para intercambiar información con dispositivos cercanos. Y algunos juegos usan eso. ---
Según la capa 3. Estaremos utilizando IP (protocolo de internet). Creo que esa es la única parte de la que podemos estar seguros. Por supuesto, hay otros protocolos de capa 3, como ICMP (usado para hacer ping y trazar rutas en la capa 4) o ARP (para obtener la dirección MAC desde una dirección IP) y RARP (obtener la IP desde MAC), pero Todos estarán al servicio de la propiedad intelectual.
Evidentemente, las direcciones IP están definidas allí. Nos preocupamos por esto. No identifican un dispositivo, sino que identifican dónde están en la red. ---
Para la capa 4, tiene una opción: UDP o TCP. Leerás que UDP no es confiable. Eso significa que no hay garantía de que un mensaje UDP llegue a su destino. A menudo lo hace. Básicamente, eso significa que si elige UDP, tendrá que implementar el reintento en el tiempo de espera, pero con TCP la infraestructura lo maneja por usted.
A veces quieres que la UDP sea poco fiable. Por ejemplo, en un juego no te importa dónde estaba el enemigo, dónde está ahora, lo que significa que no quieres recibir todas las posiciones, solo la última. Lo que también significa que no desea desperdiciar la red para asegurarse de que cada mensaje se haya transmitido, solo el último. Debido a que UDP es más versátil, sin embargo, TCP es más fácil para empezar. ---
Para la capa 5 ... dime. Puede construir en este nivel en su código, o puede agregar alguna biblioteca de alto nivel para manejarlo.
Por supuesto, las capas 6 y 7 son la forma en que el usuario interactúa con ella (presentación) y su lógica de juego (aplicación).
Errata: Dije que la presentación es como la ve el usuario. Eso fue cierto cuando todos usamos terminales de texto ... Creo que actualmente se usa para significar codificación y serialización. No importa, todavía haces lo que quieras allí. ---
Por lo tanto, las capas 1 y 2 son lo que el usuario tiene (y usted puede decidir si las apoya o no), la capa 3 es la IP de su amigo, usted elige una capa 4 y las capas 5 a 7 están bajo su control.
Entonces, ¿cómo escribir código de capa 5? Sockets
Usas sockets, construyes todo sobre los sockets.
Muy bien, entonces ... el sistema operativo recibe un mensaje de red, ¿cómo sabe cómo enviarlo a su aplicación? Bueno, su aplicación debe informar al sistema operativo que desea recibir información. ¡Pero espera! Podría haber múltiples aplicaciones que quieran recibir información. ¿Cómo los manejamos? Bueno, cada uno toma un puerto.
Cuando creas un socket de servidor, eso es lo que estás haciendo. Le está diciendo al sistema operativo que recibirá información de la red en un puerto determinado. Si el puerto es tomado por otra aplicación, esto falla. Cuando destruye / desecha el socket del servidor, el puerto se libera.
Por otro lado, necesitas un socket de cliente. Este necesita conocer la dirección IP y el puerto del servidor, para que pueda enviarle datos. Puede especificar un puerto de origen o dejar que el sistema le asigne uno. De cualquier manera, el servidor recibirá el mensaje, con su dirección IP de origen y el puerto de origen. Eso significa que ahora el servidor puede usar esa información para enviar una respuesta al cliente.
Notas:
- Lo que envíes podría ser dividido en múltiples mensajes. Es una buena idea descifrar el MTU (Unidad de transmisión máxima) para que lo envíe en trozos que no excedan eso, evitando que se rompa lo que envía. Eso es, en particular, útil para UDP, porque entonces sabes qué es lo que podría perderse si se pierde el datagrama.
- He estado diciendo "mensaje", pero si es UDP los llamamos datagramas, y si es TCP, los llamamos paquetes.
Eso es lo básico. Las bibliotecas construyen encima de eso. Muchas cosas...
Han reintentado la lógica. Tienen priorización. Los tener registros de eventos. Tienen serialización estatal. Disponen de habitaciones a las que los clientes pueden suscribirse. Etc.
Sin embargo, si desea enviar una cadena. Todo lo que necesitas son enchufes. Convierta esa cadena en una matriz de bytes (utilizando una codificación conocida) y envíela.
Sobre NAT, redes móviles y perforaciones UDP.
La traducción de direcciones de red permitirá que un enrutador o puerta de enlace oculte su dirección IP. Tendrá una dirección IP privada que solo es útil en la LAN; sin embargo, cuando se conecta a un servidor fuera de la LAN, la puerta de enlace con NAT hará la solicitud desde su propia IP pública, luego, cuando reciba una respuesta, Te lo envía a través de la LAN. Al hacer esto, el servidor nunca vio su IP privada.
Por lo general, el cliente inicia la comunicación. Para solicitar una página web, escriba la URL en el navegador, por ejemplo. Sin embargo, si desea que un servidor pueda establecer una conexión con usted ... por ejemplo, de un teléfono a otro ...
Bueno, necesitarías reenviar un puerto. Es decir, le diría al enrutador o puerta de enlace que todo lo que se envíe a un puerto en particular debe reenviarse a una IP privada en particular en la LAN. ¡Pero espera, dejar eso adentro es un riesgo de seguridad! ¿Cómo podríamos hacer esto solo cuando lo necesitamos? UPnP hace eso.
Sin embargo, si está en una red móvil, no se está conectando a un enrutador o puerta de enlace que está bajo su control, sino a uno que pertenece al ISP, que está ubicado, quién sabe dónde ... además:
- Puedes moverte a una entrada diferente, a medida que te mueves.
- La misma puerta de enlace podría darle diferentes direcciones IP cada vez (DHCP).
- Esa pasarela podría estar detrás de otro NAT.
Lo que significa que, incluso si el enrutador ISP quisiera colaborar con UPnP (lo cual es poco probable), no funcionará para usted.
Entonces necesitas la perforación de agujeros UDP. Para que funcione, necesitas:
- Para averiguar sus direcciones IP públicas.
- Comunicar la dirección IP a la otra parte.
- Para engañar al NAT y dejar pasar los datagramas. Lo que se hace enviándolos muy cerca en el tiempo (NTP puede ayudar con eso).
Por lo que yo sé, usamos STUN para eso. La idea es que necesita un servidor de señalización que se utilice para que sus clientes estén de acuerdo. Tenga en cuenta que este no es un servidor de retransmisión (no se está retransmitiendo, eso sería TURN), sino que permite a los clientes intercambiar direcciones IP y acordar un momento para realizar la perforación.
¿Se puede hacer sin el servidor de señalización? Sí, claro. Las personas pueden intercambiar direcciones IP e iniciar la conexión "al mismo tiempo" (es decir, muy cerca en el tiempo).
Comentarios
Publicar un comentario