🚀 go-pugleaf

Sergio escribi� en mensaje <01bd595b$bb6caf00$286414ac@Segio.SYSECA.ES>...
>
>�Alguien me podr�a contar de forma clara y breva como se enruta la
>informacion en TCP?

Hasta donde yo s�, TCP no "enruta", sino que controla los procedimientos de
"saludo" entre el origen y el destino y se encarga de verificar que la
informaci�n se env�a adecuadamente (TCP=Transfer Control Protocol).  El
protocolo relativo al encaminamiento en la red es IP (IP=Internet
Protocol).  Puesto que ambos procesos son complementarios y necesarios
(controlar que la informaci�n se env�a y recibe correctamente, y por qu�
camino), a cierto conjunto de protocolos de comunicaci�n se los conoce
gen�ricamente por los dos, en cierta manera m�s importantes: TCP/IP.

Yendo al caso, IP 'enruta' la informaci�n mediante dos conceptos
principales: descubrimiento de rutas y establecimiento de su coste.
Puesto que resulta ineficiente en una red en malla dar a cada uno de sus
nodos toda la informaci�n sobre c�mo alcanzar cualquiera de los dem�s (lo
que resulta en tener que almacenar del orden de 2^n datos en cada nodo,
donde n es el n�mero de nodos de la red), lo que se hace es que cada nodo
conozca �nicamente por d�nde llegar a sus nodos vecinos, de este modo y
mediante un proceso recursivo (en el que se usa el protocolo ICMP, tambi�n
perteneciente a la familia de TCP/IP) es posible descubrir todas las
posibles rutas que unen A con B, habiendo almacenado en cada nodo
�nicamente una cantidad discreta de informaci�n, que adem�s es local, con
lo que es independiente de cualquier alteraci�n lejana en la topolog�a de
la red.  Exactamente esto es lo que buscaba la gente de ARPANet, los que
'inventaron' Internet: en �ltimo t�rmino estaban pagados por el Pent�gono,
que quer�a buscar un modo para mantener su red de comunicaciones aun en el
caso de ca�da de un n�mero cualquiera de nodos (el caso era as�: En caso de
guerra nuclear, si existe un camino cualquiera para comunicar Washington
con Los Angeles, aunque sea pasando por Singapur, queremos un procedimiento
capaz de encontrarlo).  El problema del procedimiento es que es
tremendamente ineficiente: en un entorno "comercial" en el que, en general,
no existe la necesidad *imperiosa* de conectar A con B *a cualquier precio*
(en tiempo y en dinero), hay que establecer procedimientos que limiten el
n�mero de mensajes de "descubrimiento" que se vuelcan a la red, evitar que
esos mensajes entren en rutas c�clicas (de las que no pueden salir) y,
cuando se descubren m�ltiples rutas, establecer cu�l es "la m�s barata" (en
coste de tiempo y/o dinero): de este modo, en Internet es posible recibir
el famoso mensaje 'Unreachable host' en casos en los que, en realidad, s�
se le puede alcanzar (pero es demasiado lento/caro).
De estos algoritmos hay varios m�s o menos compatibles: el concepto com�n
es que todos se basan, de nuevo, en el "descubrimiento local", cada nodo
cuenta �nicamente con informaci�n de lo que lo rodea inmediatamente, pero
no trata de ir m�s all�.  Hay que destacar que, desde el punto de vista
algor�tmico, este tipo de procedimientos no es capaz de encontrar, en
general, la soluci�n �ptima al problema "Camino m�s corto (m�s barato) para
unir A y B", pero que, tambi�n en general, asegura encontrar una soluci�n
"aceptable" en *la mayor�a* de los casos.

>�Los algoritmos de encaminamiento tienen en cuenta la distancia al
destino?
>� o s�lo la saturaci�n de la l�nea?

Como te comento, depende del protocolo en cuesti�n, pero se pueden tener en
cuenta uno, otro o los dos factores a un tiempo, dependiendo de las
circunstancias.

>�Podr�amos conectarnos a un servidor en Madrid, pasando por medio mundo?

T�cnicamente s�.  En la pr�ctica, t� no controlas por d�nde va a ir una
conexi�n dada (a menos que seas t� quien controle todos los nodos
intermedios), y adem�s, por lo que he comentado anteriormente sobre el
establecimiento del camino �ptimo en Internet, si el camino es demasiado
"largo", se te devolver� un mensaje de host inalcanzable.

Si te interesa *concretamente* saber si puedes conectar con Madrid (desde
otro punto de Espa�a) a trav�s de "medio mundo" como dices, debes saber
que, aunque el caso te�rico implique que los nodos est�n conectados "todos
con todos" esto no es as�: Telef�nica (y los dem�s teleoperadores) tienen
l�neas dedicadas para la conexi�n radial y s�lo se pueden usar esas:
adem�s, entre dichas rutas, como son pocas y se conocen perfectamente no se
procede literalmente a "descubrir" las rutas existentes, sino que est�n ya
"preconfiguradas".  Como ejemplo, el centro en el que trabajo tiene dos
sedes, una en Zaragoza y otra en Jaca (Huesca); puesto que no tenemos
conexi�n directa entre ambas, una se�al de Zaragoza a Jaca sigue este
camino:

Sale de la sede en Zaragoza.
Va a la Universidad de Zaragoza (esto es un organismo p�blico)
Va a Madrid (router de entrada/Salida con Zaragoza).
Va al redirector del CSIC
Pasa al router de salida Madrid/Jaca
Llega a la sede de Jaca

Si este camino no est� disponible, ya no hay otro, y se da la paradoja de
que el camino es m�s "largo" que una simple llamada provincial
Zaragoza-Huesca, debido a la topolog�a eminentemente radial de nuestra Red
(de todas maneras, estamos en tr�mite de cambiar esto).

En la pr�ctica, si quieres saber por d�nde exactamente se esta verificando
una conexi�n dada, puedes utilizar el comando 'trace route' que te indicar�
(mediante el env�o de paquete ICMP), los nodos que se est�n 'tanteando'
(esto puede ser importante: durante la fase de descubrimiento, lo que ver�s
son las distintas tentativas que se siguen, como tratando de resolver un
laberinto --que es exactamente lo que est� haciendo-- y ves c�mo la se�al
puede entrar en un "callej�n sin salida", vuelve hacia atr�s y sigue por
otro ramal.

>�Que es lo que ocurre en la mayor�a de las conexiones, como media general?
>Necesito una generalizaci�n del estilo: Pues si, en general se enruta
>dependiendo de la m�nima distancia.
>

Es que tu pregunta no es tiene demasiado sentido: lo que existe es una
"superficie de costos" que tiene en cuenta *localmente* ambas variables,
con coeficientes de ponderaci�n diversos, desde 1/0 hasta 0/1 (esto es,
cada nodo decide c�mo alcanzar a sus vecinos inmediatos teniendo en cuenta
c�mo ponderar el tiempo frente al costo "como le da la gana").
Como norma general, s� te puedo decir que, en general, puesto que los
backbones de Internet los forman l�neas dedicadas (el tel�fono siempre est�
descolgado, lo uses o no lo uses), el factor determinante es, en este caso,
el tiempo (funci�n directa del n�mero de saltos y de la saturaci�n de los
segmentos que unen cada uno de esos saltos), ya que el coste, si todo lo
dem�s es igual, es el mismo.  Por otro lado, all� donde las conexiones se
establezcan "bajo demanda" (el tel�fono se descuelga s�lo cuando es
necesario) siempre suelen tenerse en cuenta ambos factores, por lo general,
para obtener la conexi�n m�s barata (precio por segundo de cada posible
ruta, por el tiempo que se emplea para mover un volumen dado de informaci�n
por cada una de ellas), aunque pueden existir factores adicionales, como el
tipo de informaci�n (para establecer la "fiabilidad m�nima" que requiere
cada tipo de informaci�n).
SALUD,
Jes�s