La ciencia utiliza con frecuencia los experimentos mentales para investigar la naturaleza de las cosas mediante el empleo de un escenario hipotético que nos ayude a comprender cierto razonamiento o algún aspecto de la realidad. Uno de los más famosos es el experimento mental del gato de Schrödinger, donde el pobre animal lleva 85 años en una caja, estando vivo/muerto.
Las ciencias de la computación no escapan a esto y tienen su propia batería de interesantes problemas mentales (experimentos mentales, no psiquiátricos), entre los que se encuentra el Problema de los dos generales, también llamado Problema de las dos armadas o Problema del Ataque Coordinado. Está relacionado con el más general Problema de los generales bizantinos, que no trataremos en esta entrada.
Según Wikipedia: El problema es una analogía con un escenario de guerra en el que dos ejércitos se preparan para atacar una ciudad fortificada. Los ejércitos están acampados cerca de la ciudad, cada uno en una colina. Un valle separa ambas colinas y el único modo que tienen los generales de comunicarse es mediante el envío de mensajeros por el valle. Desafortunadamente, en el valle se encuentran los defensores de la ciudad y existe cierta posibilidad de que capturen a cualquiera de estos mensajeros (enterándose y/o alterando el mensaje). Téngase en cuenta que aunque los dos generales se han puesto de acuerdo en que atacarán, no han acordado el momento de hacerlo.
Los dos generales deben atacar la ciudad a la vez para no fracasar. Deben, por tanto, comunicarse y decidir el momento oportuno.
 |
|
|
El primer general puede comenzar diciendo “Atacaremos el 4 de agosto a las 09:00”. Sin embargo, una vez enviado, el primer general no tiene la certeza de si el mensajero llegó al otro lado. Cualquier tipo de incertidumbre puede llevar al primer general a dudar de las acciones a tomar. Si los generales no atacan coordinados, la guarnición de la ciudad rechazará la vanguardia y disminuirá considerablemente sus fuerzas.
Sabiendo esto, el segundo general puede mandar una confirmación de nuevo al primero: “He recibido el mensaje y atacaremos el 4 de agosto a las 09:00 según lo acordado”. Sin embargo, ¿qué pasaría si el mensajero no llegó a su destino? Alternativamente, y como precaución, se define entonces que el segundo mensaje podría decir simplemente: “Recibido el mensaje”. Pero ¿si el mensaje fue capturado? ¿Cómo saber que no fue alterado?
Se hace evidente que no importa cuántas veces se confirme la información, no hay forma de garantizar -según este planteamiento- que ambos generales manejan la misma información.
Las preguntas más obvias que surgen al analizar este problema son: ¿Qué tiene que ver un asedio descoordinado con la computación? ¿Por qué no mandan señales de humo?
Resulta que este experimento mental refleja los problemas y retos de diseño involucrados en la coordinación de una acción mediante una comunicación que utilice un vínculo poco fiable, por ejemplo, los que conforman Internet.
Internet, omnipresente hoy día, es un conjunto descentralizado de redes de comunicación que utilizan la familia de protocolos TCP/IP, lo cual garantiza que las redes físicas heterogéneas que la componen constituyan una red lógica única de alcance mundial. Lo que mantiene unido a toda la Internet es el protocolo de capa de red IP (Internet Protocol).
A diferencia de los protocolos de capa de red anteriores, IP fue diseñado desde el inicio considerando la operación entre redes diferentes, su función es encontrar la mejor forma de llevar paquetes de datos del origen al destino, realizando su “mejor esfuerzo”, sin garantías. En un flujo de paquetes IP entre un origen y destino, puede haber pérdida o llegar fuera de orden, lo que no es adecuado para muchas de las aplicaciones que utilizamos.
La mayoría de las aplicaciones requieren de una comunicación confiable y ordenada y aquí entra TCP (Protocolo de Control de Transmisión), el caballo de batalla de Internet. TCP funciona encima de IP y su función es proveer un flujo de bytes confiable punto a punto, siendo resistente frente diversos tipos de fallas, como puede ser la pérdida de paquetes.
 |
Desde el punto de vista de TCP/IP, se consideran poco fiables todos los canales de comunicación y el cierre de una conexión TCP requiere coordinación. Liberar una conexión fuera de tiempo puede conllevar pérdida de datos (una transferencia de cientos de gigabytes que resulte inútil porque unos pocos bytes no se recibieron) o sobrecarga en servidores (no cerrar a tiempo las conexiones en un servidor web de alta demanda puede llevar a una denegación de servicio).
Para garantizar que los datos sean enviados sin errores, cada vez que se recibe satisfactoriamente un paquete TCP, el receptor envía al emisor un “acuse de recibo” (ACK) comunicándole que cierto paquete fue recibido, si el emisor detecta que algún paquete de los que ha enviado no tiene su ACK correspondiente después de cierto tiempo, lo reenvía.
 |
| Cierre de conexión TCP según el estándar |
 |
| Desconexión abrupta con pérdida de datos |
Al igual que nuestro Problema de los dos generales no puede ser resuelto, no es posible liberar una conexión TCP con total seguridad ante una pérdida de paquetes. En la práctica se utilizan temporizadores, si una de las partes intenta cerrar la conexión y no recibe respuesta, luego de cierto tiempo simplemente se cierra, mientras que si no se recibe información eventualmente se cierra también por inactividad. Los problemas generados por estas inconsistencias deberán ser resueltos entonces por las capas superiores.
 |
| Cuatro escenarios del protocolo TCP para liberar una conexión: a) Normal, b) ACK final perdido, c) respuesta perdida y d) respuesta perdida y siguientes peticiones de desconexión perdidas. Tomado de Redes de Computadoras, 5ta edición, Andrew S. Tanenbaum y David J. Wetherall |
De forma muy simplificada hemos dado un vistazo a las complejidades escondidas en acciones tan comunes como revisar su blog favorito.
Comentarios
Publicar un comentario