El modelo ISO/OSI y TCP/IP
Cada nivel incluye su propia cabecera / cola en el mensaje a enviar, con los datos necesarios para implementar su protocolo
Los protocolos de bajo nivel
Nivel físico: Este nivel se dedica a transmitir los 0’s y los 1’s.
Cuántos voltios se emplearán para codificar los 0’s y cuántos para los 1’s
Cuántos bits/segundo
Comunicación simplex/duplex
Tamaño, forma y características de los conectores
Ejemplo: RS-232
Nivel de enlace: Asegurar transmisión libre de errores.
Agrupar bits en grupos de bits (tramas)
Aplicar códigos de redundancia a las tramas para detectar errores.
En caso de errores, enviar mensajes de control para pedir la retransmisión.
Nivel de red: Encaminar los mensajes de una máquina a otra.
A este nivel a los mensajes se les llama paquetes.
Ejemplo: IP, parte de la pila de protocolos de Internet.
Los protocolos de bajo nivel
Ejemplo de protocolo de enlace de datos
DATAGRAMA EN CAPA 3
Protocolos de transporte
Objetivo: Asegurar la fiabilidad de las comunicaciones
Los mensajes enviados desde las aplicaciones (o desde los niveles superiores del modelo OSI), son divididos en paquetes, que serán reensamblados en el destino.
Los paquetes que no lleguen a su destino, serán retransmitidos.
Ejemplos: TCP, UDP
TCP, sobre IP: ofrece mensajes fiables con conexión.
UPD, sobre IP: ofrece mensajes no fiables sin conexión. (sin retransmisiones)
¿Cómo funciona TCP para cliente/servidor?
a) Mensajes necesarios para hacer una petición cliente/servidor mediante TCP
b) Interacción cliente/servidor mediante TTCP (Transactional TCP)
SEGMENTO EN CAPA 4
Protocolos de alto nivel
Por encima del nivel de transporte, OSI define 3 niveles más. En la práctica, los tres se engloban en uno sólo: el nivel de aplicación.
Nivel de sesión: Proporciona control sobre la conversación y proporciona facilidades de sincronización. Por ejemplo para realizar ‘checkpoints’ y de esta forma tolerar fallos.
Nivel de presentación: Dedicado a tratar el significado de la información que se transmite. Por ejemplo registros en lugar de bits.
Nivel de aplicación: Los protocolos específicos necesarios para dotar de funcionalidad a determinado sistema: FTP, HTTP, MAIL, TELNET, etc.
Protocolos de middleware
Middleware es software que según en modelo OSI reside en el nivel de aplicación.
Sin embargo, contiene muchos protocolos de propósito general, que podrán ser empleados por aplicaciones.
Hay multitud de protocolos que soportan gran variedad de servicios. Por ejemplo:
Protocolos de autenticación
Protocolos de compromiso atómico
Protocolos de gestión de cerrojos distribuidos
Protocolos para proporcionar mecanismos de comunicación de alto nivel: RPC, RMI, etc.
El modelo ISO/OSI, reescrito contemplando el nivel de middleware.
Las operaciones send y receive
El paso de un mensaje se puede soportar con dos operaciones de comunicación:
Send
un proceso envía un mensaje a un destino
receive
un proceso recibe el mensaje en el destino
Cada destino tiene asociada una cola
los emisores añaden mensajes a la cola
los receptores los extraen
Comunicación síncrona y asíncrona.
El paso de un mensaje
Implica: comunicación de datos
desde el proceso emisor hacia el receptor
Puede implicar: sincronización de los procesos
Comunicación síncrona:
emisor y receptor se sincronizan en cada mensaje
el send y el receive son operaciones bloqueantes
el emisor se bloquea hasta que el receptor hace receive
el receptor se bloquea hasta que llega un mensaje
Comunicación síncrona y asíncrona
Comunicación asíncrona:
el send es no bloqueante
el mensaje se copia a un buffer local y el emisor continúa (aunque aún no haya un receive)
el receive puede ser bloqueante o no bloqueante
receive no bloqueante:
el receptor provee un buffer para cuando llegue el mensaje y continúa tras emitir el receive (aunque no haya mensaje)
Implica notificación (sondeo, interrupción)
receive bloqueante
En entornos multitarea
pocas desventajas: otras tareas pueden seguir activas
grandes ventajas: tareas receptoras sincronizadas a mensajes entrantes
el receive no bloqueante parece más eficiente pero es más complejo (¿interrupciones? no, gracias)
Los servidores pueden esperar indefinidamente, pero en otros casos: temporización (timeout)
Los sockets
Mecanismo original de IPC en UNIX: pipes
cauce unidireccional (stream) y sin nombre
enlazan filtros, sin sincronización explícita
pipeline. Ej.: gunzip -c fich.tar.gz | tar xvf –
un mismo padre crea los procesos filtro y los pipes
Útil en entornos productor-consumidor
No es útil en SD:
no hay nombre no hay enlace
no hay posibilidad de envío de mensajes discretos
A partir de BSD 4.2, IPC implementada como:
llamadas al sistema: capa por encima de TCP/UDP
socket = destino de mensajes
a través del que se pueden enviar mensajes, y por medio del cual se pueden recibir mensajes
La IPC tiene lugar entre 2 sockets
Cada socket debe estar asociado a:
un puerto local de su máquina
una dirección IP de dicha máquina
un protocolo (UDP o TCP)
Sólo el proceso que posee el socket puede
recibir mensajes destinados al puerto asociado
En Java: – clase InetAddress y nombramiento mediante DNS
La comunicación mediante datagramas UDP
Datagrama:
Mensaje autocontenido no fiable desde un emisor a un receptor único, sin asentimientos ni reenvíos
no hay garantía de la entrega
transmisión entre 2 procesos send + receive
cada proceso debe crear un socket
y enlazarlo a un puerto local
los servidores, a un puerto de servicio determinado
los clientes, a cualquier puerto local libre
la operación receive entrega:
el mensaje transmitido
el puerto al que está enlazado el socket emisor
Se usa comunicación asíncrona con receive bloqueante:
el send retorna tras pasar el mensaje a las capas inferiores (UDP/IP)
éstas lo transmiten y lo dejan en la cola del socket asociado al puerto de destino
el receive
(pendiente o futuro) extrae el mensaje de la cola
por defecto, bloqueo indefinido; si se necesita:
multitarea ? crear procesos y/o hilos
espera acotada ? temporización
por defecto, se puede enviar a (y recibir de) cualquier puerto
es posible limitarlo a uno concreto: conexión
La comunicación mediante datagramas UDP
Datagrama: Continuación
No hay garantía de la recepción
los mensajes se pueden perder
por errores de checksum o falta de espacio
los procesos deben proveer la calidad que deseen
Añadiendo asentimientos, se puede dar un servicio fiable sobre uno no fiable
¿Por qué no usar una comunicación perfectamente fiable?
no suele ser imprescindible
causa cargas administrativas grandes:
almacena información de estado en origen y destino
transmite mensajes adicionales
posible latencia para emisor o receptor
Ejemplo: C y datagramas UDP
Ejemplo: Java y UDP
Java proporciona 2 clases: DatagramPacket y DatagramSocket
DatagramPacket:
– soporte a los datagramas
– y el constructor que usan los emisores toma:
• un mensaje, su longitud, la dirección IP de la máquina destinataria y el número de puerto local del socket destinatario
– el constructor que usan los receptores toma:
• un array de bytes para un mensaje y su longitud
DatagramSocket:
– soporte a los sockets
– el constructor que usan los servidores toma:
• el número de puerto local que se quiere asociar
– el constructor que usan los clientes
• sin argumentos: elige uno cualquiera que esté libre
– métodos adicionales:
• send y receive: su argumento es un ejemplar de
DatagramPacket
La comunicación mediante cauces (streams) TCP
La abstracción de cauce (stream) oculta:
tamaño de los mensajes
los procesos leen o escriben cuanto quieren
las capas inferiores (TCP/IP) empaquetan
mensaje perdidos
mediante asentimientos y reenvíos
control de flujo
evita desbordamiento del receptor
mensajes duplicados y/o desordenados
mediante identificadores de mensajes
destinatarios de los mensajes
una vez establecida una conexión, los procesos leen
y escriben del cauce sin necesidad de volver a usar sus respectivas direcciones
La comunicación mediante cauces (streams) TCP
• Dos papeles diferenciados:
cliente, crea un socket encauzado y:
solicita el establecimiento de una conexión (connect)
servidor, crea un socket de escucha
con una cola de peticiones de conexión
lo asocia a un número de puerto determinado
espera la llegada de peticiones de conexión
Cuando el servidor acepta una conexión:
se crea automáticamente un nuevo socket encauzado
conectado al del cliente por un par de cauces (streams):
cada proceso lee de su cauce de entrada y
escribe en su cauce de salida
si un proceso cierra su socket
se transmiten a la cola del destino los datos pendientes e
indicación de cauce roto
La comunicación mediante cauces (streams) TCP
Bloqueo:
lectura: si no hay datos disponibles
escritura: si la cola del socket de destino está llena
Opciones para atender a múltiples clientes:
escucha selectiva (en UNIX, select)
multitarea:
se crea un nuevo proceso que atiende la conexión establecida
el proceso original sigue atendiendo el socket de escucha
multiproceso (en UNIX, fork)
hilos (threads)
Los procesos deben ocuparse de la concordancia de los datos
Si errores graves de red ? conexión rota
Utilización de TCP:
HTTP, FTP, Telnet, SMTP.
La comunicación mediante cauces (streams) TCP
ServerAddress y ClientAddress son direcciones de socket
La comunicación mediante cauces (streams) TCP
• ServerSocket:
– soporte a los sockets de escucha (servidores)
– método accept:
• si cola de solicitudes de conexión vacía, se bloquea
• si no,
– toma una solicitud
– crea un ejemplar de la clase Socket
– establece la conexión
» con sus dos cauces
– retorna una referencia al Socket creado
• Java proporciona 2 clases:ServerSocket y Socket
• Socket:
– soporte a los sockets encauzados
– el cliente usa un constructor que:
• toma como argumentos el nombre del host y el número de puerto del servidor
• crea el socket y
• solicita automáticamente la conexión
– servidor: resultado del accept
– métodos: getInputStream y getOutputStream
• retornan valores de tipo InputStream y OutputStream
• se pueden usar como argumentos para constructores
de cauces de E/S
– ej: DataInputStream y DataOutputStream
La Alineación y la RepresentaciónExterna de Datos
La información almacenada dentro de los programas en ejecución se representa mediante estructuras de datos. La información transportada en los mensajes consiste en secuencias de bytes.
Las estructuras de datos deben ser aplanadas a secuencias de bytes para su transmisión y reconstruidas en recepción.
Diferentes formas de representar tipos primitivos: int, float…
Ejemplo: variantes en la ordenación de enteros:
Big endian: byte más significativo en la posición más baja de memoria
Little endian: byte menos significativo en la posición más baja de memoria
Métodos para que 2 computadoras puedan intercambiar datos:
1. Los valores se convierten a un formato externo acordado antes de la transmisión y se revierten al formato original en recepción.
2. Los valores se transmiten según el formato del emisor, junto con una indicación de formato utilizado y el receptor los convierte si es necesario.
La Alineación y la RepresentaciónExterna de Datos
Representación externa de datos: estándar acordado para la representación de estructuras de datos y valores primitivos:
Empaquetado (marshalling): convertir estructuras de datos y datos primitivos en una representación externa, aplanada, para ser transmitida.
Desempaquetado (unmarshalling): reconstruir las estructuras de datos y datos primitivos a partir de una representación externa.
Ejemplos de representación extena de datos
SUN's External data representation (XDR)
CORBA's Common Data Representation (CDR)
Java's object serialization
ASCII (XML, HTTP)
Llamada a procedimiento remoto (RPC)
Creado por Birrel & Nelson en 1984
Permiten a los programas llamar procedimientos localizados en otras máquinas
Un proceso x en una máquina A, puede llamar un procedimiento localizado en una máquina B
Información puede llevarse del proceso invocador al invocado dentro de los parámetros
RPC utiliza el modelo de paso de mensajes y el patrón arquitectónico cliente/servidor para la ejecución de procedimientos que no residen en el mismo proceso
Ejecución de una llamada de procedimiento local
(Gp:) Variables locales
al main
(Gp:) Variables locales
al main
(Gp:) Variables locales
al main
(Gp:) bytes
(Gp:) buf
(Gp:) fd
(Gp:) dirección regreso
(Gp:) SP
(Gp:) SP
(Gp:) SP
(Gp:) a) Stack antes llamada read
(Gp:) b) Stack durante ejecución read
(Gp:) c) Stack después llamada read
(Gp:) main()
{
:
count = read(fd, bytes, buf)
:
}
(Gp:) main()
{
:
count = read(fd, bytes, buf)
:
}
(Gp:) main()
{
:
count = read(fd, bytes, buf)
:
}
Local Procedure Call (LPC): conocido modelo de llamadas a procedimientos locales usado para transferir control y datos
Ejecución de una llamada de procedimiento local
La invocación local a procedimientos consiste en seguir cierta convención (protocolo) de paso de argumentos y de cambio del contador de programa.:
Se colocan en la pila los argumentos y el contador de programa
Se salta al procedimiento.
El procedimiento obtiene los argumentos de la pila y se ejecuta.
Los resultados del procedimiento se colocan en la pila.
Al finalizar el procedimiento se retorna al punto de origen, obteniendo el contador de programa original de la pila.
Todo este trabajo lo hace el compilador de forma transparente al programador!!
Si colocamos los procedimientos en máquinas diferentes a la máquina que invoca, tendremos llamada a procedimiento remoto.
Llamadas a procedimiento remoto
Ejecución remota de procedimientos
Programación estructurada
No obstante, las soluciones actuales para objetos distribuidos pueden ser vistas como una extensión de RPC. Ej: CORBA, JavaRMI (Remote Method Invocation), .NET Remoting
Llamadas a procedimiento remoto
Con las llamadas a procedimiento remoto hay que tener en cuenta que queremos la misma transparencia de ubicación que tiene el programador que utiliza procedimientos convencionales:
Queremos ocultar al cliente el hecho de que el procedimiento está ubicado en otra máquina.
Queremos que el programador del cliente, simplemente invoque i=suma(j,k) y por “arte de magia”, la invocación llegue a la máquina remota
Esta “magia” se consigue en RPC mediante los stubs.
Llamadas a procedimiento remoto
(Gp:) Máquina Cliente
(Gp:) Máquina Servidor
(Gp:) kernel
(Gp:) kernel
(Gp:) stub del
cliente
(Gp:) stub del
servidor
(Gp:) cliente
(Gp:) call
(Gp:) return
(Gp:) Pack
parámetros
(Gp:) Unpack
resultado
(Gp:) Unpack
parámetros
(Gp:) Pack
resultado
(Gp:) servidor
(Gp:) call
(Gp:) return
(Gp:) Mensaje transportado en la red
Llamadas a procedimiento remoto
(Gp:) kernel
(Gp:) kernel
(Gp:) Máquina Cliente
(Gp:) Máquina Servidor
(Gp:) sum
(Gp:) sum
(Gp:) 4
(Gp:) 7
(Gp:) 4
(Gp:) 7
(Gp:) mensaje
(Gp:) mensaje
(Gp:) sum(i,j)
int i,j;
{
return(i+j);
}
(Gp:) :
:
n=sum(4,7);
:
:
Llamadas a procedimiento remoto
Los stubs los debe generar el compilador.
Tanto el programador del programa cliente, como el programador del procedimiento remoto ignoran la existencia de los stubs: transparencia.
Nótese que el procedimiento servidor podría invocar otro procedimiento ubicado en una tercera máquina (incluso en la máquina “cliente”):
Más que de máquina (proceso) cliente o máquina (proceso) servidora, hay que hablar de cliente y servidor para un procedimiento en particular, puesto que el rol cliente/servidor debe entenderse por procedimiento
Llamadas a procedimiento remotoPaso de Parámetros
El stub cliente debe:
Empaquetar los argumentos en un mensaje.
Enviar el mensaje de invocación al servidor.
Esperar el mensaje de respuesta.
Desempaquetar los resultados (argumentos de salida) del mensaje de respuesta
Devolver los resultados al código que invocó al stub.
El stub servidor debe:
Esperar mensaje de invocación
Desempaquetar los argumentos de la invocación.
Realizar la invocación al procedimiento local y esperar a que termine.
Empaquetar los argumentos de salida en el mensaje de respuesta.
Enviar la respuesta al cliente.
Llamadas a procedimiento remotoPaso de Parámetros
Además de los parámetros, hay que pasar “algo” que identifique al procedimiento que se desea invocar: por ejemplo el nombre del procedimiento.
Esto es necesario para permitir que una máquina tenga más de un procedimiento invocable.
Llamadas a procedimiento remotoPaso de Parámetros
Al empaquetado de argumentos se le llama marshaling.
Al desempaquetado de argumentos se le llama unmarshaling.
Paso de argumentos por valor (argumentos de entrada): el programa cliente copia los argumentos al stub, el stub lo envía por la red, el stub servidor copia los argumentos al procedimiento remoto. Se procede de igual forma con los argumentos de salida.
Paso de argumentos por referencia (resultados, argumentos de salida o argumentos de entrada/salida):
¿Cómo se pasa un puntero? En general no se puede.
Para pasar por referencia, lo habitual suele ser pasar por valor, pero el stub cliente debe sobrescribir los datos que reciba de la red encima de los argumentos que recibió del programa cliente.
¿Cómo se sabe si los argumentos son de entrada, de salida, o de entrada/salida? depende del lenguaje!
Por este motivo se creó IDL (Interface Definition Language): En él se especifican argumentos in, out e inout. Con esta interfaz, el compilador crea los stubs realizado correctamente el paso de argumentos.
Invocación de métodos locales yremotos
Las invocaciones de métodos entre objetos en diferentes procesos, tanto si es en el mismo computador o no, se conocen como “invocaciones de métodos remotas”.
Las invocaciones entre objetos del mismo proceso son invocaciones de métodos locales
•RMI es una extensión de invocación a métodos locales que hace que un objeto que reside en un proceso pueda invocar métodos de otro objeto que reside en otro proceso distinto
Objeto remoto y su interfaz remota
Las interfaces especifican los tipos de los argumentos, valores devueltos y excepciones de los métodos de un objeto que pueden invocarse remotamente sin indicar su implementación
Una llamada a un procedimiento remoto (RPC) es a RMI lo que una llamada aprocedimiento es a una invocación al método de un objeto
Invocación de Métodos Remotos (RMI) Objetos distribuidos
Sistemas OO en general
Los objetos encapsulan datos (estado) y operaciones sobre los datos (métodos).
La única forma de acceder a los objetos es mediante llamadas a sus métodos.
Los objetos pueden tener múltiples facetas, es decir, pueden implementar múltiples interfaces.
Esta distinción entre objeto e interfaces es clave!
Una interfaz no es más que la lista de los métodos, detallando sus argumentos, que satisface cierta clase de objetos.
Objetos distribuidos
Para invocar a un objeto remoto con transparencia de ubicación (de forma similar a RPC):
El cliente del objeto invocará a un stub cliente (llamado proxy)
El proxy enviará la invocación al stub servidor por la red.
El stub servidor, llamado esqueleto, invocará al objeto.
Nótese que tanto el objeto remoto como el proxy implementarán la misma interfaz.
Invocación de Métodos remotos (RMI) Objetos distribuidos
Objeto distribuido = objeto remoto + proxy + esqueleto
El proxy y el objeto remoto tienen la misma interfaz.
Para invocar un objeto remoto, el cliente invoca al proxy y la invocación llegará al objeto remoto.
Invocación de Métodos remotos (RMI) Objetos distribuidos
ORB = Object Request Broker: Gestor de invocaciones a objeto.
El ORB es una capa de software que facilita el desarrollo de aplicaciones distribuidas orientadas a objeto.
Proporciona servicios utilizados por los proxies, los esqueletos y por el código de las aplicaciones.
La misión más importante del ORB es dirigir las invocaciones desde los proxies a los esqueletos adecuados situados en la máquina adecuada.
Referencias a objeto
Una de las diferencias más importantes entre los sistemas RPC y los sistemas OO distribuidos consiste en la posibilidad de los sistemas OO de pasar objetos como argumento en las invocaciones.
Por valor: se copia todo el objeto y el objeto remoto que recibe la invocación recibe una copia del objeto.
Por referencia: el objeto remoto recibe una referencia al objeto.
En los sistemas de objetos distribuidos, es clave el paso de objetos por referencia
Un proceso tiene que informar al ORB que dispone de un objeto invocable. Para ello registra el objeto:
Como resultado del registro:
El ORB crea un esqueleto que permitirá dirigir las invocaciones remotas al objeto
El ORB retorna una referencia al objeto. Lo habitual será que retorne un proxy que contendrá la referencia al objeto (Oref)
Referencias a objeto
Contenido de las referencias a objeto:
Dirección física del ORB que contiene el objeto (por ejemplo: IP + puerto)
Identificador del objeto dentro de la máquina (una máquina puede tener más de uno)
Interfaz que se registra (un objeto puede tener más de una)
Paso de referencias:
Referencias a objeto
Ejemplo de paso de referencias: supongamos que la máquina A tiene una referencia a O1 y otra a O2. Supongamos que la máquina B tiene la implementación de O1 y la máquina C, tiene la implementación de O2.
Referencias a objeto
Ejemplo de paso de referencias (cont): Supongamos que la máquina A invoca al método op1 de O1, pasándole como argumento el objeto O2. Es decir, La máquina A invoca O1.op1(O2)
Como resultado, la máquina B, recibe una referencia al objeto O2
Introducción y Objetivos a Servicios de Nombres
Introducción
Necesidad de nombres para:
referirse a recursos: usuarios, servicios, puertos, ordenadores, etc.
seleccionar un recurso determinado dentro de un conjunto
comunicar y compartir recursos en un sistema distribuido
comunicar usuarios en un SD
Objetivos
Conocer el Servicio de Nombres:
lo usan los procesos clientes para obtener losatributos de los recursos a partir de sus nombres
Analizar las cuestiones de diseño:
el espacio de nombres
el mecanismo de resolución
los mecanismos de división, replicación y cache de datos
Estudiar un caso:
DNS: Internet Domain Name System
Generalidades de los servicios de nombres
Base de datos de enlaces:
{nombres} « {atributos}
Principal operación: resolución de un nombre
Otras operaciones: crear, listar y borrar enlaces
Nombre ? clave simple
? múltiples componentes
Buscados en contextos: partes separadas de la BD
Espacios de nombres
Espacio de nombres: colección de nombres válidos reconocidos por un SN
Válido ? se intentará buscarlo
no necesariamente enlazado
Un SN retorna atributos para los nombres válidos enlazados a objetos
Opciones:
nombres estructurados: su estructura interna representa su posición en una jerarquía
nombres planos
• Espacios de Nombres jerárquicos:
– más manejables que los EN planos
– no hay necesidad de una autoridad central
– mantienen (sin conflictos) atributos de objetos relacionados
– cada parte de un nombre se resuelve de forma relativa a un contexto
– los diferentes contextos se pueden gestionar de forma separada
• Se pueden usar alias para facilitar el empleo de los nombres
Los nombres en DNS
En DNS: nombre = nombre de dominio
estructura de árbol:
ND = 1 o más etiquetas separadas por “.”
dominio = colección de ND
• En la práctica, sólo una de uso generalizado: nombramiento en Internet
Espacio de nombres DNS de Internet está dividido de forma:
organizativa: com, edu, gov, mil, net, org, int (USA)
y geográfica: es, us, uk, fr
En algunos países:
división organizativa debajo de la geográfica
La administración de los dominios se puede delegar en los sub-dominios
el nombre del sub-dominio se debe acordar con los gestores del dominio superior
Los servidores de DNS no reconocen nombres relativos
Los nombres en DNS
La resolución de los nombres
Resolver = buscar un nombre para obtener sus atributos asociados
Es un proceso iterativo:
comenzando por un contexto inicial,
el nombre se presenta repetidamente ante sucesivos contextos de nombramiento que establecen la correspondencia entre un nombre dado y:
un conjunto de atributos primitivos, u
otro contexto de nombramiento y un nombre derivado
Navegación: localización de datos a través de varios SN
La iterativa suele realizar un agente de usuario:
un AU en cada computadora, trabajando para los clientes de ese computadora
comprueba la validez del nombre y va contactando a los SN determinada información se aprende de un archivo de configuración
la dirección del SN local y/o de la raíz, …
Navegación controlada por servidor
El AU contacta con un SN, que coordina la resolución:
y le pasa el resultado de vuelta al AU
No recursiva:
El SN actúa como el AU de la navegación iterativa
• Recursiva:
a) El SN contacta con otro SN
b) este 2º SN intenta resolver el nombre, y, si no lo tiene:
c) contacta con otro SN que almacene un prefijo (más largo) del nombre
el proceso sigue (y vuelve) recursivamente
El mecanismo de cache
Es la llave de las prestaciones de los SN
Ayuda a mantener la disponibilidad de los servicios ante caídas
En la práctica, reduce al mínimo los accesos a los SN de alto nivel
Tiene éxito porque los datos cambian infrecuentemente
Fácil detectar datos obsoletos al usarlos
La cache es la razón para que AU = proceso, y no librería:
compartición de cache ? ahorro de búsquedas, aunque
impone cargas adicionales a las computadoras clientes
El Sistema de Nombres de Dominio(DNS )
Origen del DNS
Su principal base de datos de nombramiento se usa en Internet
Esquema previo a DNS:
Archivo maestro central con nombres y direcciones de las computadoras
transferido por FTP a las computadoras que lo necesitaban
Problemas:
no crecía bien para grandes números de computadoras
las organizaciones locales desean administrar sus sistemas de nombres
se necesita un servicio general de nombres
Generalidades del DNS
Principales objetos nombrados:
computadoras: atributos = direcciones IP
dominios
Se puede nombrar cualquier tipo de objeto
Arquitectura libre: gran variedad de implementaciones posibles
Delegación: cada organización (y suborganización) gestiona sus datos
Escala mundial ? millones de objetos
Principales mecanismos usados:
a) Partición jerárquica de la base de datos de nombramiento
b) Replicación
c) Cache
El Sistema de Nombres de Dominio(DNS )
Especificación de las consultas de DNS
En DNS se pueden almacenar atributos arbitrarios
Una solicitud se especifica por:
un ND:(in-addr.arpa = ND especial: números IP de redes)
una clase:
para distinguir la base de datos de Internet de otras
un tipo:
hay un {tipos} particular para cada base de datos
Principales consultas de DNS
1) Resolución de nombres de computadoras
En general: resolución = nombre computadora ? dirección IP
Ejemplo:
al programa de ftp se le da el ND nic.ddn.mil
?ftp consulta al DNS:
ND = nic.ddn.mil + designación de tipo = A
? retorno: la dirección IP de esa computadora
el daemon de ftp de esa computadora debe correr en un nº de puerto conocido
el programa de ftp puede construir el identificador completo del destino
El Sistema de Nombres de Dominio(DNS )
El Sistema de Nombres de Dominio(DNS )
Localización de servidor de correos
resolución = nombre de dominio ? dirección IP servidor de correo
– Ejemplo:
mensaje para usuario@det.uvigo.es
? consulta al DNS:
ND = det.uvigo.es + designación de tipo = MX
? retorno:
lista de computadoras que aceptan correo para det.uvigo.es
Concepto de zona
Los datos de nombramiento se dividen en zonas
Cada zona contiene:
los atributos para los ND de un dominio, menos:
los sub-dominios administrados por autoridades de menor nivel
ND y dirección de SN que proveen datos autoritativos para la zona:
versiones que se puede confiar en que son razonablemente actuales
ND de SN que mantienen datos autoritativos para subdominios delegados
y las direcciones de esos SN
El Sistema de Nombres de Dominio(DNS )
Hay 2 tipos de SN que proveen datos autoritativos de cada zona:
a) SN primario: lee directamente el archivo maestro de la zona
b) SN secundario: carga los datos desde un SN primario
esto se llama transferencia de zona
periódicamente, el SS contacta con el SP para comprobar si coinciden
si copia secundaria obsoleta:
el SP envía la más reciente
frecuencia de comprobación es un parámetro de zona
1 o 2 veces al día
El Sistema de Nombres de Dominio(DNS )
• Todo SN puede conservar en su cache datos de otras zonas
condición: avisar al cliente de que no son datos autoritativos
tiempo-de-vida:
parámetro de zona, asociado a cada entrada
un SN no autoritativo lo anota al obtener datos de uno autoritativo
sólo proporciona un dato de la cache durante ese tiempo
transcurrido: nueva consulta ? recontactar SN autoritativo
minimiza volumen de tráfico, pero retiene la flexibilidad:
tiempo-de-vida adaptado a la variabilidad de los atributos
Los servidores de nombres. Ejemplo
Navegación. Procesado de consultas
En DNS: AU = resolver
acepta consultas,
las formatea en los mensajes esperados en el protocolo DNS, y se comunica con 1 o más SN
Utiliza un simple protocolo solicitud-respuesta:
UDP sobre Internet (los SN de DNS están en puertos conocidos)
usa temporizaciones y reenvíos, y una lista de SN iniciales, en orden de preferencia
DNS admite navegación tanto recursiva como iterativa:
cuando el resolver contacta con un SN especifica el tipo de navegación
pero los SN no están obligados a implementar la recursiva
Los datos de zona se almacenan en registros de recursos
Cada registro:
se refiere a un Nombre de Dominio
es de un tipo, a elegir entre varios tipos diferentes
para la base de datos de nombramiento de Internet:
– A, NS, CNAME, SOA, WKS, PTR, HINFO, MX, TXT
 Página anterior | Volver al principio del trabajo | Página siguiente  |