Introducción
Dado el auge de los juegos con características "online" y que ademas estamos en un foro pertinente a uno de estos juegos se hace necesario explicar de forma breve como realmente funciona esto que mal denominamos Internet y que características determinan nuestra jugabilidad.
En definitiva, lo que se va a intentar en este hilo es explicar que coño es eso de ping y porque con mis 100 megas tengo 300ms.
Indicar que realmente lo que me motivo a escribir esta guía fue un post por parte del usuario [NICK]esteso.
El primero que quiero que entendáis (Aparte de que Internet no es Google) es entender que lo que denominamos Internet no es mas que una mezcla heterogénea de distintas redes donde numerosas organizaciones y entidades donde cada uno intenta seguir la estandardiza TCP/IP a su manera.
En el caso que nos atañe tenemos numerosos participantes, en un principio estará nuestra red domestica (Si, tienes un router tienes una red domestica), para continuar con la red de nuestro proveedor de Internet, luego distintos organismos gubernamentales y distintos "proveedores" de Internet (En adelante ISP) que ira haciendo que nuestra conexión "salte" entre distintos nodos hasta, finalmente, alcanzar el ISP de Gameforge, su red local y sus servidores (Todo esto se puede monitorizar y os enseñare como hacerlo mas adelante).
Historia de Internet... bueno, mejor dejémonos de historias...
Internet nace como medio para compartir hiper-documentos científicos usando una tecnología militar (ARPANET). Desde ahi ha evolucionado hasta lo que manejamos hoy en día, por el camino se han ido estableciendo ciertas "normas" de como deben hacerse las cosas, lo que al fin y al cabo se denomina estándar.
Para entender esto ultimo debéis comprender que cuando se define algo en términos de informática se determina como y cuando algo debe hacerse, dando normas para que todos los sistemas tengan piezas "interoperables", porque, en Informática, existen miles de formas de solucionar un unico problema. Un ejemplo es que para pintar un simple carácter como puede ser la letra "a" requiere una gran coordinación entre numerosos componentes de un único sistema. Por suerte, a dia de hoy, esto es una tarea trivial ya que trabajamos con componentes virtuales (Software) que facilitan esto en raíz a distintos estándares de comunicación que se han establecido a nivel físico (Hardware).
Imaginad la dificultad de comunicar dos sistemas distintos, donde no solo dispongan de hardware distinto (Distinta arquitectura de procesador por ejemplo) si no que incluso operen con un sistema operativo distinto. Para solventar estas limitaciones nació la estandardiza TCP/IP que, al final, se convirtió en la base de lo que hoy conocemos como Internet.
TCP/IP o como hacemos que A y B hablen entre ellos
TCP/IP es la base de Internet, todos los sistemas que utilizan esta gran red se comunican usando los conceptos básicos de este protocolo.
TCP/IP es un sistema en capas, donde la capa mas inferior es las mas cercana al funcionamiento físico mientras que la mas superior es la que permite trabajar de una forma abstracta. Esta división en capas permite a los programadores abstraerse de como se transmiten la información (Si es por ondas, por cable etc) y centrarse en como su aplicación debe gestionar la comunicación.
Como están estructuradas las distintas capas de TCIP/IP y donde se asientan cada uno de los protocolos
Empezando de abajo arriba tenemos lo siguiente:
Physical Layer bip bip bip
En esta capa se vana a asentar los protocolos que van a permitir que dos dispositivos se comuniquen de forma física. Esto quiere decir que si un ordenador y un router están comunicados a través de un cable, el protocolo que usaran (Ethernet) debe indicar que voltajes deben usar, tiempos etc. Si, en cambio, lo hicieran a través de Wifi (802.11) cuales deben ser las frecuencias, tiempos de espera etc.
Lo importante es que en esta capa solo se permite la comunicación directa de sistema a sistema, por lo cual, dichos sistemas deben estar situados de forma próxima.
Data Link Layer
Si en la capa anterior definíamos como dos dispositivos próximos pueden comunicarse a través de un medio en esta capa crearemos la primera abstracción a fin de que "se entiendan" (En esta capa se establecen muchos mecanismos de redundancia de datos a fin de poder establecer mecanismos de comprobación de errores):
Mientras que en la capa anterior se definía como iba a interpretarse los distintos cambios del medio a fin de determinar su valor, en esta capa se intenta genera lo que se denomina como trama, un conjunto de cambios de estado que tendrán representación binaria "01001101".
En esta capa se define lo que se conoce como MAC Address o direcciones físicas. Todos los componentes de comunicación (Ya sean Ethernet, Wifi, etc) poseen una dirección única la cual no puede ser duplicada, esta diseccionar es la que permite identificar un dispositivo en una red local como receptor de una trama especifica..
Imagen de una etiqueta situada en un router que indica su MAC Address
Network Layer [em]Una dirección IP para dominar el mundo...[/em]
En la capa anterior eramos capaces de poder comunicarnos con cualquier dispositivo a nuestro alcance indicando su dirección MAC. A partir de esta capa podremos comunicarnos con el resto del mundo.
Para ello nace el direccionamiento IP, o como algunos dirian, esos 4 numeros que dicen donde resido... Una dirección ip es un conjunto de 4 bytes (32 bits) expresados en su forma decimal sin tener en cuenta su valor negativo. Cada conjunto puede tomar un valor que oscila desde el 0 hasta el 255, de esta forma, obtenemos IPs tales como 216.58.214.163 (google.es), 79.110.83.131 (gameforge.com), etc.
El protocolo, a fin de comunicar distintas redes entre ellas, utiliza lo que es conocido como enrutamiento, mediante el enrutamiento, los datagramas (conjuntos de tramas proporcionados por la capa anterior) viajan por dintos enrutadores hasta alcanzar el destino.
Esquema que presenta la telaraña de Internet
Tomando la imagen anterior, cuando un datagrama del cliente quiere alcanzar el servicio de Internet se efectúa aproximadamente las siguientes operaciones:
- El ordenador cliente envía a su puerta de enlace (Su router) el datagrama especificando la IP del servicio.
- El primer ruter comprueba la IP del servicio, si tuviera registrado un camino para dicho rango de IP enviara directamente el datagrama, si no, enviara una petición de "discover" al resto de ruters conocidos a su alcance.
- Cuando el resto de ruters reciben el "discover" buscan en su registro a ver si tienen el camino, en caso negativo mandan otra petición de "discover".
- El proceso se continua hasta que el ruter al que esta conectado el servicio contesta indicando que el "conoce" la IP, asi que empieza a mandar señales hacia atrás a fin de establecer el camino
- Con el camino ya establecido el primer ruter envía el datagrama al ruter escogido y este lo replica.. asi hasta alcanzar el servicio.
Esto es una aproximación y una abreviación de como funciona el direccionamiento IP, se que cometo algunas falacias pero explica de forma escueta mas o menos como funciona
Es por lo que cuando hablamos de Internet hablamos de saltos ("hops") que nuestra señales deben atravesar al fin de alcanzar el destino.
Quote
Direcciones IP de los distintos servidores
[INTL] Stormwing - 79.110.83.66
[INTL] Sillus - 79.110.83.69
[FR] Ragnarok - 79.110.83.70
[DE] Odin - 79.110.83.72
Para conocer el numero de "hops" que se realizan entre tu cliente y una dirección IP tenemos de serie la herramienta tracert en Windows (traceroute en Linux) que nos permite saber por cuantos ruters nuestros datagramas trasncurren hasta alcanzar la dirección indicada
Traza al servidor de Hellion
Transport Layer
En la capa anterior ya podíamos llegar a la puerta de un sistema y entregarla un datagrama, el problema ahora radica que un sistema puede estar corriendo numerosas aplicaciones al mismo tiempo así que deberíamos de poder indicar a que aplicación hemos de entregar dicho datagrama. Para eso, esta capa determina que a cada segmento (básicamente un datagrama IP con información adicional) posee un identificador de aplicación denominado comúnmente "puerto", de forma que el sistema operativo es capaz de otorgar a la aplicación que es encuentra en la capa superior un segmento que le pertenece y no el de una aplicación distinta.
A parte de asignar puertos esta capa ordena los segmentos otorgados por la capa inferior (pueden venir en ordenes distintos a los que fueron enviados), así como comprobación de errores, etc.
En esta capa se asientan dos protocolos muy importantes, conocidos como TCP y UDP.
- TCP: establece sincronía entre emisor y receptor, es decir, una serie de pasos al fin de que la conexión se inicie, se mantenga abierto y por ultimo se cierre.
- UDP: Es un protocolo sin sincronía, tras "abrir" una conexión se empiezan a enviar mensajes sin sincronización entre emisor y receptor y se puede cerrar de forma abrupta.
A efectos sencillos estas son las diferencias, indicar que TCP hace que cada segmento tenga un mayor peso (mayor cantidad de bytes) que el protocolo UDP pero permite gestionar de una forma mas eficiente un recurso limitado como es el máximo de conexiones que se pueden establecer.
Application Layer o como hacer que todo esto valga la pena
En la parte superior tenemos la capa de aplicación, donde realmente los programadores y desarrolladores nos movemos. En esta capa se pueden ubicar muchísimos protocolos como HTTP, FTP, P2P, etc... es donde construimos nuestras aplicaciones que usaran las capas inferiores para lograr una comunicación que nosotros interpretaremos.
A nivel de programación habitualmente hablamos de sockets, que son conexiones TCP entre una aplicación cliente y una aplicación servidora. Cuando el socket se encuentra en la aplicación cliente lo llamamos como un socket saliente mientras que cuando radica en la aplicación servidora tenemos los sockets a la escucha (Realmente tendremos una fabrica de sockets como indicamos mas abajo).
Os pondré un ejemplo de como utilizamos este "stack" los programadores a fin de crear una aplicación simple que responda todos los mensajes que reciba.
Aplicacion cliente
1. Se crea un socket TCP dando como destino la dirección IP del servidor así como el puerto en el cual estará a la escucha
2. Se inicia la conexión del socket
3. Se envía un mensaje a través del socket, en este ejemplo el mensaje sera la cadena de texto plana "hola"
4. Esperamos que el servidor conteste creando un mini bucle que estará pendiente de si recibimos datos por parte del servidor
5. Una vez recibimos el mensaje completo del servidor, lo imprimimos por pantalla
6. Cerramos el Socket
Aplicacion servidor
1. Creamos una "fabrica de sockets" a la escucha en un puerto determinado, esta fabrica lo que hará es esperar conexiones entrantes y, al recibir una, generara un socket con al conexión ya establecida (Habra hecho el Handshake o el saludo TCP).
2. Una vez tenemos el socket abierto con el cliente, esperamos a recibir su mensaje con un minibucle.
3. Tras recibir el mensaje escribimos en el socket la respuesta, el texto plano "ey, ¿que tal estas?"
4. Volvemos a poner el socket a la espera de que el cliente cierre la conexión (Podria cerrarlo el servidor... pero para este ejemplo mejor lo dejamos abierto).
5. Recibimos el cierre de socket por lo cual lo eliminamos.
Si se ejecutara en una maquina la aplicación cliente funcionaria exactamente igual que si se ejecuta en 1000 maquinas distintas sin importar la ubicacion donde residan las maquinas. Para esto es para lo que sirve todo el stack TCP/IP.
y dos piezas a +15 seguiré aguantando un mojón pero bueno.. sino fuera por esos momentos el juego no sería tan divertido, la cara que se le debió de quedar al que me mataba...
