Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
El módulo UDP (User Datagram Protocol) [RFC768] es un fino recubrimiento a la capa IP que cumple las funciones equivalentes al nivel OSI de Transporte de datagramas. Proporciona un servicio sin conexión y, por ello, de baja fiabilidad. No se garantiza la entrega de los datagramas, ni su llegada en orden o no duplicación. Los servicios que requieran un sistema de transporte fiable deben emplear el TCP (Transport Control Protocol) o algún esquema similar, como la familia de protocolos TPx de OSI.
A pesar de todo existen servicios perfectamente válidos en un entorno de funcionamiento poco fiable y, por otra parte, en una red local -por ejemplo- la sobrecarga asociada a un protocolo más seguro puede resultar inaceptable. La calidad de servicio intrínseca es ya lo bastante elevada.
Las características de este módulo son:
En cuanto a los servicios que utilizan este módulo, destacan:
La interfaz de este módulo está constituida por procesos y por subrutinas ejecutadas en el contexto del llamante. Su utilización es muy simple.
PROC_UDP_BC
Este proceso es el encargado de inicializar este módulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". La inicialización de este módulo debe ser posterior a la del módulo IP.
PROC_UDP_SUP
Este proceso se hace cargo de la transmisión de datagramas. Espera mensajes "MSG_MBUF". campo1 contiene una cadena de dos o más MBUFs, el primero de ellos conteniendo una cabecera UDP interfaz y el resto los datos en sí. La cabecera UDP interfaz se define como:
typedef struct {
uint16 puerto_fuente;
uint16 puerto_destino;
uint16 dont_fragment;
uint16 dummy;
} udp_header;
Los campos "puerto_fuente" y "puerto_destino" identifican el puerto UDP al cual va dirigido el datagrama dentro de la máquina destino, y el puerto al cual tendrá que dirigir su posible respuesta. Si "dont_fragment" vale cero se admite la fragmentación del datagrama, mientras que si vale uno será destruido si excede el MTU de alguna de las redes intermedias. El valor de "dummy" es arbitrario.
campo2 contiene la dirección IP fuente (una de las nuestras), mientras que en campo3 se envía la dirección IP del destino. Ambos valores deben estar en formato HOST.
PROC_UDP_INF
Este es el proceso que procesa los datagramas UDP recibidos por la capa IP, y gestiona los mensajes de control provenientes de ICMP.
Este es el tipo de mensaje más normal que este proceso espera recibir. Contiene un datagrama UDP según el formato definido por la capa IP.
Este proceso también envía mensajes "MSG_MBUF" hacia arriba. En ese caso campo1 contiene una cabecera UDP interfaz y el datagrama en sí (en dos MBUFs, respectivamente). campo2 contiene la dirección origen y campo3 la dirección destino del datagrama. Los campos "dont_fragment" y "dummy" de la cabecera UDP interfaz contendrán valores indefinidos.
El proceso recibe este mensaje de la capa ICMP. El formato es el definido en el capítulo dedicado a ICMP. No se informa a la aplicación superior.
Si el proceso recibe este mensaje proveniente de la capa ICMP, envía hacia arriba, al proceso que gestiona el puerto fuente original, otro mensaje "MSG_ICMP_DEST_UNREACHABLE" con campo1 obedeciendo al formato UDP interfaz, mientras que campo2 proporciona información adicional (ver el capítulo ICMP) y campo3 contiene la dirección IP de la máquina a la que no se puede llegar (formato HOST).
En cuanto a rutinas, tenemos:
estado udp_alta_puerto(uint16 puerto,proc_id proc_retorno);
Esta rutina da de alta un puerto UDP para escucha. Cualquier datagrama que llegue al puerto "puerto" será enviado al proceso cuyo identificador sea "proc_retorno". Esta rutina retorno "OK" si todo fue bien, "ERR_EN_USO" si el puerto especificado ya ha sido declarado con anterioridad y "ERR_OVERFLOW" si hay demasiado puertos declarados.
uint16 udp_alta_puerto_arbitrario(proc_id proc_retorno);
Esta rutina es idéntica a la anterior pero asigna un puerto cualquiera que esté libre. Por compatibilidad con posibles servicios superiores, el puerto asignado será siempre mayor o igual que 1024. Retorna el valor del puerto asignado, o cero si hay demasiados puertos declarados.
void udp_baja_puerto(uint16 puerto);
Esta rutina da de baja un puerto previamente declarado. Cualquier datagrama UDP que se reciba hacia ese puerto será rechazado con un error ICMP.
estado udp_flujo(uint32 ip,uint16 tamanho);
Esta rutina proporciona un mecanismo de control de flujo UDP. Cuando algún proceso desea enviar un datagrama utilizando este protocolo debe pedir permiso antes mediante el empleo de esta llamada. "ip" contiene una de nuestras direcciones origen y "tamanho" es el número de bytes que deseamos transmitir. Retorna "OK" si tenemos el flujo abierto, "FLUJO_LLENO" si nos prohibe la transmisión y "ERR_INVALID" si la dirección especificada no es nuestra. Si el control de flujo está cerrado podemos reintentarlo otra vez tras un tiempo prudencial (una décima de segundo, por ejemplo).
Aún cuando el control de flujo esté cerrado, la capa UDP se hará
cargo de cualquier datagrama que se envíe. Esto es así para
simplificar ciertos protocolos, pero no debería abusarse de esta
característica si no se está completamente seguro de sus
implicaciones.
Implementación
Este módulo sigue escrupulosamente todas las guías definidas en [RFC768], implantándolo completamente. Aunque el protocolo original tiene la posibilidad de no emplear suma de control en los datagramas, hemos decidido implementarla debido a que ello no supone una pérdida de eficiencia detectable. Todos los datagramas salientes, por tanto, incluyen una suma de control. No obstante, por compatibilidad, se admiten datagramas UDP entrantes tanto con suma de control como sin ella.
En la implementación actual los mensajes de control de flujo, "MSG_ICMP_SOURCE_QUENCH", son ignorados. La razón de ello es que no resulta sencillo definir un mecanismo de control de flujo y congestión en un sistema de datagramas. Por otra parte el protocolo UDP no suele suponer una carga apreciable y los esquemas de temporización y reintentos de las capas superiores suelen ser suficientes para reducir este problema.
Cualquier datagrama UDP que se reciba hacia un puerto no declarado
será destruido y se generará un mensaje
"MSG_ICMP_DEST_UNREACHABLE" con el código "ICMP_NO_PUERTO" para
informar a la máquina fuente de que el puerto especificado no
existe. Si lo que llega es un datagrama con una suma de control
errónea (si tiene suma de control), lo eliminamos sin ninguna
acción adicional. No podemos arriesgarnos a generar un mensaje
ICMP porque el datagrama estaba corrupto y no podemos contar
con que la información de encaminamiento recibida sea correcta.
Bibliografía
[RFC768] RFC768: "User Datagram Protocol"
Jon Postel
Agosto 1.981
[RFC862] RFC862: "Echo Protocol"
Jon Postel
Mayo 1.983
[RFC863] RFC863: "Discard Protocol"
Jon Postel
Mayo 1.983
[RFC1034] RFC1034: "DOMAIN NAMES - CONCEPTS AND FACILITIES"
P. Mockapetris
Noviembre 1.987
[RFC1035] RFC1035: "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION"
P. Mockapetris
Noviembre 1.987
[RFC1057] RFC1057: "RPC: Remote Procedure Call Protocol
specification version 2"
Sun Microsystems, Inc
Junio 1.988
[RFC1094] RFC1094: "NFS: Network File System Protocol
Specification"
Sun Microsystems, Inc.
Marzo 1.989
[RFC1122] RFC1122: "Requirements for Internet Hosts --
Communication Layers"
Robert Braden
Octubre 1.989
[RFC1813] RFC1813: "NFS Version 3 Protocol Specification"
B. Callaghan
B. Pawlowski
P. Staubach
Junio 1.995
[RFC1831] RFC1831: "RPC: Remote Procedure Call Protocol
Specification Version 2"
R. Srinivasan
Agosto 1.995
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
