-- Leo's gemini proxy
-- Connecting to elpamplina.duckdns.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
por: elpamplinadecai@gmail.com
El protocolo UDP es el sustituto de TCP como protocolo de transporte, cuando no se requiere una entrega confiable. En determinadas aplicaciones, lo importante es que los datos lleguen cuanto antes, aunque esto signifique que se pierdan algunos. En ese caso, se usa UDP en lugar de TCP.
UDP utiliza el protocolo IP subyacente para transportar un mensaje de una máquina a otra, proporcionando la misma semántica de entrega sin conexión y no confiable. No genera asentimientos, no controla el flujo ni ordena los mensajes entrantes. El único trabajo que añade a el de IP es la identificación de los procesos dentro de las máquinas origen y destino, extremos finales de la comunicación, además del cómputo de la suma de verificación (checksum).
Parece evidente que el destinatario final de un mensaje enviado es un proceso corriendo en la máquina destino. Ésta normalmente estará corriendo muchos procesos al mismo tiempo, por lo que es necesario identificar al destinatario de cada mensaje.
Especificar un identificador de proceso (PID) en particular en una máquina remota como destino final de un datagrama no es muy buena idea. Varias son las complicaciones:
Los procesos se crean y destruyen contínuamente de manera dinámica.
El transmisor rara vez conoce el funcionamiento interno de la otra máquina para identificar los procesos en ella.
El receptor puede necesitar reemplazar el proceso que está recibiendo una comunicación por otro (p.e. un proceso hijo), sin necesidad de reestablecerla o informar al otro extremo.
Se necesita acceder a los servicios de una máquina sin conocer internamente los procesos que los proporcionan.
Un proceso puede necesitar tener abiertas varias conexiones de red, necesitandose alguna forma de seleccionarlas.
Debido a estos inconvenientes, es necesario dejar de pensar en los procesos como destinos finales y establecer unos puntos abstractos de destino, llamados puertos de protocolo.
En la mayoría de los sistemas operativos se proporciona un acceso síncrono a los puertos de protocolo, es decir, el proceso que intenta extraer datos del puerto antes de la llegada de éstos queda bloqueado en espera de ellos. En combinación con este mecanismo, se cuenta con un buffer de memoria intermedia que guarda los datos que van llegando y aún no han sido leídos por el proceso cliente.
Para establecer una comunicación, por tanto, el transmisor necesitará conocer, además de la dirección IP de la máquina destino, el número de puerto donde desea enviar los datos. Los números de los puertos origen y destino de cada datagrama van en la cabecera UDP (o TCP).
Para identificar unívocamente a un flujo de datos en particular son necesarios los dos pares dirección IP/puerto de origen y destino.
A los mensajes UDP se les llama datagramas de usuario.
Los campos de la cabecera tienen 16 bits cada uno. Entre ellos hay una suma de verificación (checksum) de tal manera que se puede controlar si el datagrama ha llegado intacto. Aunque este campo es opcional (se puede hacer 0), es casi obligado su uso, pues es la única manera de hacer esta comprobación. Recuérdese que el checksum de IP sólo se refiere a los campos de su cabecera y que la verificación que se pueda hacer a nivel de enlace sólo tiene sentido dentro de la misma red.
El campo puerto origen se empareja con la dirección IP de origen (de la cabecera IP) y el puerto destino con la dirección IP de destino. A todos los efectos, estos cuatro campos son los que identifican unívocamente una comunicación entre dos máquinas dentro de la red de redes.
El campo de longitud incluye los octetos del encabezado.
La forma de computar la suma de verificación de UDP es algo extraña. Se intenta que el checksum sirva no sólo para detectar errores, sino para comprobar que el datagrama ha llegado al destino donde fue enviado.
Para comprobarlo no basta con mirar los números de puerto de la cabecera UDP, pues éstos no diferenian unas máquinas de otras. Es necesario incluir las direcciones IP dentro de la suma de verificación, aun cuando éstas no forman parte del datagrama UDP.
Para resolver esta aparente contradicción, la máquina origen monta una pseudo-cabecera que incluye:
Direcciones IP de origen y destino
Un octeto 0 de relleno, para alinear en palabras de 32 bits.
El código de 8 bits del protocolo según el estándar IP (17 para UDP).
Un campo de 16 bits para la longitud del datagrama (sin incluir el pseudo-encabezado).
Esta información debe coincidir con la de la cabecera IP.
Una vez montada la pseudo-cabecera, se pone a cero el campo checksum de la cabecera UDP, se computa la suma del pseudo-cabecera, la cabecera y el paquete de datos en complemento de 16 bits y se almacena en dicho campo. La pseudo-cabecera no se transmite realmente, y es desechada.
Cuando el datagrama llega a su destino, la máquina receptora debe volver al construir el pseudo-encabezado usando la información de la cabecera IP y comprobar la suma de verificación.
Observese que este truco es una clara violación de la arquitectura en capas, que se ha hecho por motivos puramente prácticos. Esto hace que UDP dependa claramente de IP y más concretamente del formato de su cabecera, lo cual es muy criticable.
@ElPamplina@masto.es
elpamplinadecai@gmail.com
-- Response ended
-- Page fetched on Thu May 9 11:55:08 2024