Comunicacin en los Sistemas Operativos Distribuidos

M.C. Juan Carlos Olivares Rojas

2.1 Comunicacin
Para lograr la distribucin de procesos se requiere de mecanismos que permitan coordinar y controlar la ejecucin de procesos en ambientes no centralizados, ya sean de manera local y remota. Los primeros protocolos para la distribucin de procesos remotos fueron para mquinas homogneas.

Comunicacin
Otra forma de comunicacin fue la estandarizacin de sistemas heterogneos con interfaz comn UUCP (Unix to Unix Copy Protocol) que dio origen a los comandos R (rcopy, rlogin, rsh). rlogin jcolivar@antares.itmorelia.edu.mx rsh jcolivar@antares.itmorelia.edu.mx

Comunicacin
La comunicacin entre procesos (IPC) es parte fundamental de las primitivas de sincronizacin de un sistema distribuido. Los mecanismos de comunicacin entre procesos no slo aplican a aplicaciones distribuidas sino a cualquier tipo.

Comunicacin
El mecanismo de comunicacin entre procesos ms famosos es el IPC (Inter Process Comunication) de Unix System V. El otro punto a tratar es sobre los mecanismos de intercomunicacin entre entidades de procesamiento diferentes con diferentes sistemas operativos: POSIX.

2.1.1 Sockets
Los sockets son el mecanismo sincronizacin distribuida ms importante. de

Se les denomina conectores por que pueden unir un proceso cliente y un proceso servidor, de manera semejante a como se puede unir un enchufe de un dispositivo elctrico con su respectivo zcalo.

Sockets
El mecanismo de sockets ms conocido es el referente a la API de Berkeley. Est API est implementado en prcticamente todos los sistemas Unix, por lo que se maneja C, pero tambin est portado a otras arquitecturas como Windows (WinSock) y a otros lenguajes como Java

Sockets
Los sockets trabajan sobre capa 4 (Transporte) del modelo OSI, aunque algunos autores la ubican en la capa 5 (Sesin). Para la comunicacin de procesos remotos se necesita conocer la direccin de la mquina destino y el puerto donde se va a escuchar.

Sockets
Los sockets no estn casados con ningn tipo de red, por lo que se pueden implementar en diversos protocolos de red como IPX/SPX, NetBEUI, TCP/IP, siendo este ltimo el ms importante. Para hacer uso de sockets se necesitan dos cosas: una familia o protocolo a utilizar para la comunicacin y un tipo de conexin.

Funciones de un servidor
1. Abrir el canal de comunicacin e informar a la red su direccin y su disposicin para aceptar peticiones de servicio. 2. Esperar a que un cliente pida un servicio 3. Atender un cliente (servidor interactivo) a la vez o crear un proceso hijo (servidor concurrente) 4. Volver al punto 2 para esperar nuevas peticiones.

Funciones de un cliente
1. Abrir el canal de comunicaciones conectarse a la direccin del servidor. y

2. Enviar al servidor un mensaje de peticin de servicio y esperar hasta recibir la respuesta. 3. Cerrar el canal de comunicaciones y terminar la ejecucin.

Sockets
Para establecer una comunicacin a travs de sockets se necesitan 5 requerimientos: Direccin del servidor Puerto del servidor Direccin del cliente Puerto del cliente Canal de comunicacin abierto

Sockets
Para leer datos de un socket se pueden utilizar las siguientes primitivas: read, readv, recv, recvfrom y recvmsg; siendo las ms utilizadas read y recv(sfd, buf, len, flags).

Para escribir datos en un socket se utilizan las siguientes primitivas: write, writev, send, sendto y sendmsg, siendo las ms utilizadas write y send(sfd, buf, len, flags).

2.1.2 RPC
Las llamadas a procedimientos remotos (RPC) fue el primer intento por obtener un middleware para la construccin de sistemas distribuidos. Su funcionamiento se basa en la arquitectura cliente/servidor siendo totalmente transparente para el usuario.

RPC
El problema del manejo de procesos distribuidos con sockets radica en que se basa en el flujo de E/S, haciendo los programas ms difciles de estructurar.

En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).

RPC
El nivel de transparencia en RPC es muy alto ya que el usuario no tiene que ver con detalles de conexin. La simplicidad de toda esta heterogeneidad en el llamado a un procedimiento remoto es realizado por los stubs (resguardos) tanto en el cliente como en el servidor.

RPC
Para la transferencia de datos entre los stubs, se necesita de un proceso de empacar desempacar los parmetros y resultados. Dicho proceso recibe el nombre de marshalling.

Los stubs se comunican con los ncleos de cada proceso logrando una transparencia muy alta.

RPC
Para el envo de datos se utiliza la siguiente forma cannica: Complemento a 2 los enteros, ASCII caracteres, 0 (falso) y 1 verdadero, formato IEEE decimales, todo guardado como little endian. En la prctica RPC no es lo mismo que un procedimiento local a la hora de revisar los mecanismos de fallas.

RPC
La semntica de fallas de RPC es la siguiente: 1.El cliente no puede localizar al servidor. 2.Se pierde el mensaje de solicitud del cliente al servidor 3.Se pierde el mensaje de respuestas del servidor al cliente. 4.El servidor falla antes de recibir una solicitud.

RPC
5. El cliente falla despus de enviar una solicitud.
En general existen diversas implementaciones de RPC, siendo las ms extendidas sobre TCP/IP, la cual tiene los siguientes puntos a favor:

El protocolo ya ha sido diseado, lo que ahorra trabajo considerable.

RPC
Se dispone de muchas implementaciones. Esta disponible en casi cualquier sistema Unix. Tanto TCP como UDP estn soportados por muchas redes. Las implementaciones ms evolucionadas de RPC incluye la de Sun ONC (Open Network Computing) y DCE (Distributed Computing Environmet).

RPC
RPC est desarrollado en C, pero algunas versiones permiten programar en otros lenguajes como Fortran. Las implementaciones ms actuales trabajan sobre XML formando los XML-RPC. Para la conexin entre un cliente y un servidor utilizando RPC se siguen dos pasos: localizar la mquina servidor, y localizar el proceso en esa mquina.

RPC
Para encontrar dichos servicios se necesita de un demonio RPC que se encuentre monitoreando todos los procesos remotos, dicho proceso se llama portmap , el cual escucha en el puerto 111. Muchos servicios de red utilizan RPC para funcionar, entre ellos NFS, el cual es un sistema de archivos distribuidos.

RMI
La invocacin de mtodos remotos es la versin orientada a objetos de la filosofa RPC. Los programas realizados en Java deben heredar de la clase remote. A la hora de ejecutar se deben indicar las polticas de seguridad. Esto se hace a travs del parmetro -D de java

RMI
Al proxy en el lado cliente se le llama stub, mientrs que en el servidor se le llama skeleton.
Se cuenta con la primitiva invoke(objeto, mtodo, param_entrada, param_salida); Se necesita de un proceso enlazador (binder) que una a un cliente con el objeto remoto.

CORBA
Common Object Request Broker Architecture Es un middleware para la construccin de sistemas distribuidos utilizando el paradigma de programacin orientada a objetos. Una de las principales ventajas de CORBA es que cada uno de los componentes de CORBA se pueden implementar en una gran variedad de lenguajes.

CORBA
CORBA maneja un modelo asncrono de comunicacin, aunque tambin se puede manejar un esquema de polling. CORBA utiliza muchas tecnologas estandarizadas como IOR (Interoperable Object Reference), IIOP(Internet Inter ORB Protocol), ORB (Object Request Broker Architecture), entre otras.

CORBA
CORBA es una arquitectura genrica, de tal forma que otras tecnologas de objetos como RMI se pueden ejecutar a travs de IIOP. CORBA est basado en una arquitectura de cuatro capas con proxys en el lado cliente y servidor.

Modelo de servicios Web

Clientes ricos

Browsers estndar

Dispositivos mviles

Otros servicios

XML

Servicios Web

Formularios Web Lgica aplicacin Servicios SO

Servicios Web
Los servicios Web van de la mano de las tecnologas XML. XML nos sirve para estandarizar el marshalling de los datos. Utilizar la Web nos permite tener un puerto no bloqueando por Firewall

Servicios Web
Son la invocacin de cdigo remoto utilizando protocolos estandarizados. En conclusin, realizan la misma funcin que los sockets, RPC, RMI, Corba y dems tecnologas distribuidas.
Se puede ver a los servicios Web como una analoga de un procedimiento almacenado en una base de datos.

Definicin de SW
La aplicacin que acta como cliente debe conocer: La URL del servidor remoto que ofrece el servicio, El nombre del servicio que se solicita, y Los parmetros que se deben enviar junto con la llamada al servicio.

Estos datos se enviarn mediante HTTP

Definicin de SW
El servidor que ofrece el servicio web leer los parmetros que se le han enviado, llamar a un componente o programa encargado de implementar el servicio, y los resultados que se obtengan de su ejecucin sern devueltos al servidor que solicit la ejecucin del servicio.

Servicios Web
Un servicio Web no es un XML RPC como tal, se diferencia en la forma en que trabajan. Los servicios Web forman la base de la arquitectura orientada a servicios (SOA) Los servicio Web utilizan generalmente el mtodo POST de HTTP para enviar los datos de la invocacin del servicio.

SOA (Arquitectura Orientada a Servicios)

Proveedor de Servicios

Publicar

Servicio

Conectar

Registro de Servicios

Encontrar

Solicitante de Servicio

Descripcin

Cliente

Servicios Web
Los datos viajan envueltos en un protocolo llamado SOAP (Simple Object Access Protcol) que hace el marshalling de los datos. Una de las principales caractersticas que tienen los servicios Web radica en su ubicuidad, ya que pueden ser accedidos desde cualquier sitio, utilizando inclusive cualquier otro protocolo de transporte SMTP, FTP, etc.

SOAP
Indica cmo se deben codificar los mensajes que circularn entre las dos aplicaciones. SOAP define dos modelos de mensajes:
Un mensaje de solicitud. Un mensaje de respuesta.

Servicios Web
Los servicios Web necesitan ser descritos (saber que parmetros reciben, devuelven) para poderlos utilizar en diversos clientes. Esta descripcin se realiza a travs de WSDL (Web Service Definition Language). Generalmente esas descripciones los clientes las conocen o bien, puede descubrirlas haciendo uso de UDDI (Universal Description, Discovery and Integration).

Servicios Web
La UDDI no es otra cosa que un repositorio en donde se almacenan servicios Web que pueden ser invocados por diversos clientes. Muchas empresas ofrecen servicios Web como amazon, google, http://www.xmethods.com

Pila de protocolos de SW
Redefinicin de comunicaciones toda la pila de

Basado en tecnologas estndares

Servicio web Protocolo Formato del mensaje Descripcin Descubrimiento HTTP SOAP WSDL UDDI

Ventajas de los Servicios Web

Basados en estndares.
Fcil integracin.

Desarrollo de actividades modularizadas. Independencia de plataforma.

Puede ser usado tanto en clientes ligeros como pesados (clientes heterogneos).

Desventajas de los Servicios Web

Es que no son seguros...

Es que no tienen estado...

Es que no son transaccionales... Los servicios Web no hacen ms que reinventar la rueda, pero esta vez usando XML.

Cliente de servicio Web Windows C# .NET

2.1.3 Comunicacin en Grupo

Se define a un grupo como un conjunto de procesos que actan entre ellos encierto sistema. Los grupos son dinmicos, ya que pueden aceptar nuevos procesos o estos pueden dejar a su grupo. Los grupos pueden ser abiertos o cerrados dependiendo de cmo es el paso de mensajes entre los elementos del grupo.

Comunicacin en Grupo
En base a su organizacin los grupos pueden ser de compaeros (cuando todos los procesos son iguales y para hacer elecciones hacen recuento de votos) o Jerrquico (donde existe un proceso coordinador y el resto son trabajadores). Cuando entran nuevos procesos o se salen del grupo, se debe garantizar que los mensajes lleguen a los procesos que actualmente conforman el grupo.

Comunicacin en grupo
Una de las mayores problemticas con respecto a la comunicacin en Sistemas Distribuidos es la forma en como podemos comunicar varios procesos distribuidos a la vez.

La comunicacin tradicional es del tipo puntual (unicast) o bien hacia todos con el uso de la difusin (broadcast).

Comunicacin en Grupo
El problema radica en que al hacer un broadcast los mensajes llegan hacia todas las mquinas y no hay forma alguna de discriminar hacia un grupo determinado de procesos.

Por otra parte, el hacer broadcast est limitado en muchas redes como Internet donde no existe, por este motivo suele utilizarse la tcnica de multicast.

Comunicacin en Grupo
El problema del multicast es que se necesitan de direcciones IP especiales (Clase D) para poderse llevar acabo. En la prctica se utiliza muy poco y en lugar se usa comunicacin con datagramas hacia un grupo de procesos donde la parte ms importante es la coordinacin entre procesos.

2.1.4 Tolerancia a fallos

La tolerancia a fallas es considerada la principal caracterstica que debe de tener un sistema distribuido para alcanzar el principio de transparencia.

Para lograr la tolerancia a fallos se necesita de una buena comunicacin entre procesos distribuidos y sobretodo de una correcta coordinacin entre procesos.

Tolerancia a fallos
Un Sistema Distribuido en base a coordinacin de sus procesos puede ser: la
Asncrono: no hay coordinacin en el tiempo. Sncrono: se suponen lmites mximos para el retraso de mensajes.

El primer factor a tomar en cuenta es que el canal de comunicacin este libre de errores (canal confiable).

Tolerancia a Fallos
Para garantizar que el canal sea confiable se debe de realizar lo siguiente:
Retransmisin de mensajes. Debe haber redundancia de canales La entrega de un paquete sea dentro de un tiempo lmite especificado

En general, se considera que los canales de comunicacin son fiables y que cuando falla la comunicacin es debido a la cada del proceso.

Tolerancia a Fallos
Las fallas de particin son las fallas de comunicacin ms importantes ya que fragmentan la red en pequeas reas llamadas particiones haciendo imposible el manejo de la consistencia de los datos. Son difciles de detectar ya que no son visibles para todos los nodos de la red.

Tolerancia a Fallas
Las fallas de particin pueden ser muy comunes por lo que los sistemas de archivos deben tener un mecanismo que permita reintegrar los datos una vez eliminada la particin. Esta idea atrado como consecuencia el uso de sistemas de archivos con soporte a desconexin, los cuales son tiles en entornos de cmputo mvil.

Tolerancia a Fallos

Tolerancia a Fallos

Tolerancia a Fallos
Para prevenir errores se utilizan los Detectores de Fallo, los cuales son procesos que nos indican la presencia de fallos en un sistema. Los detectores de fallos no son necesariamente exactos y la mayora de ellos se consideran Detectores de Fallo No Fiables

Tolerancia a Fallos
Este tipo de detectores se basan en que si en un tiempo mximo predefinido no reciben mensajes de los nodos, los consideran sospechosos, aunque no necesariamente han fallado, esto puede ocurrir debido a retrasos en la transmisin. Un Detector de Fallas Fiable detecta los fallos en un sistema en forma exacta y normalmente requieren de hardware y software adicional.

Tolerancia a Fallos
Para evitar fallas en los sistemas distribuidos se suelen utilizar tcnicas de duplicacin y replicacin de datos.

2.2 Sincronizacin
2.2.1 Relojes fsicos.

2.2.2 Relojes lgicos.

2.2.3 Usos de la sincronizacin (manejo de cach, comunicacin en grupo, exclusin mutua, eleccin, transacciones atmicas e interbloqueo).

Sincronizacin
La sincronizacin de procesos en los sistemas distribuidos resulta ms compleja que en los centralizados, debido a que la informacin y el procesamiento se mantiene en diferentes nodos. Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos.

Sincronizacin
Sincronizacin es la forma de forzar un orden parcial o total en cualquier conjunto de evento Se utilizan algoritmos distribuidos para sincronizar el trabajo comn entre los procesos y estos algoritmos tienen las siguientes propiedades:
inaceptable que se concentre en un nodo, a toda la informacin y procesamiento

Sincronizacin
Se debe contemplar o prever los posibles puntos de fallo del sistema. En general, la mejor forma de sincronizar procesos distribuidos es a travs del correcto diseo de los sistemas. A continuacin se muestran otras mejores prcticas para la elaboracin de sistemas distribuidos.

Diseo de Sistemas Distribuidos

El diseo de un sistema distribuido es similar al de un sistema centralizada en cierta forma. Se deben considerar todas aquellas consideraciones que involucran por definicin los sistemas operativos. Por ejemplo, se pueden utilizar tcnicas como los diccionarios de datos distribuidos.

 El objetivo de la sincronizacin de relojes es ordenar los eventos en forma cronolgica para saber cundo se efectu un evento (fecha, hora, proceso a realizar y computadora que lo hizo).
Diferencias de relojes internos en una red
8:06 8:12

2.2.1 Relojes fsicos

8:05

8:13

Sincronizacin de relojes
Hay 2 tipos de sincronizacin del reloj:

Externa: Cuando se toma el reloj de un dispositivo externo a la computadora.

Interna: Se toman los relojes internos de las computadoras con cierto margen de atraso/adelanto de los mismos. Problemtica de sincronizacin del tiempo: el tiempo es relativo

Sincronizacin del Tiempo

Se utiliza ms el trmino cronmetro que reloj para medir el tiempo en sistemas distribuidos. Aun considerando un tiempo uniforme existen problemas cuando se sincronizan cronmetros a travs de la red: No se puede calcular con exactitud el tiempo que tardar una respuesta en llegar

Relojes Fsicos
Internamente cada computadora contiene un reloj fsico, el cual cuenta la frecuencia de las oscilaciones de un cristal para medir el tiempo a travs de una estampa o marca de tiempo.

Cada mquina puede interpretar de forma distinta los pulsos de reloj, aunque la diferencia puede ser prcticamente nula, despus de un tiempo se pueden ver los efectos.

2.2.2 Relojes lgicos

Una forma ms sencilla de sincronizar el tiempo de sistemas distribuidos es a travs del uso de relojes lgicos. Un reloj lgico es una convencin utilizada para ponerse de acuerdo en cuestin del tiempo. Un ejemplo es el UTC (Universal Time Coordinated) que se basa en relojes atmicos coordinados con el astronmico.

Sincronizacin de Relojes
Otros ejemplos de relojes lgicos se pueden obtener a travs de satlites artificiales como es el caso de GPS. El tiempo se puede sincronizar aparentemente de forma fcil si se modifica con respecto al tiempo UTC, el detalle radica en que puede afectar la ejecucin de procesos. Cierto tipo de hardware permite modificar la frecuencia de reloj para mejor sincronizacin.

Sincronizacin de Relojes
El ajuste de tiempo se hace de manera gradual.

Existen diversos algoritmos de sincronizacin de relojes, a continuacin se detallan algunos de ellos.

Algoritmo de Cristhian: es el ms sencillo consiste en utilizar un servidor de reloj y medir los tiempos de latencia, dichos tiempos se consideran en el tiempo formal

Algoritmo de Cristhian
En su versin original es poco tolerante a fallas, se suelen utilizar varios servidores de tiempo y el cliente hace comunicacin a travs de un multicast.

Algoritmo de Berkeley
Como medir el tiempo de retraso con exactitud es imposible, el Algoritmo de Berkeley sugiere que se coordinen todos los relojes de los nodos en un tiempo t en especfico.

NTP
Network Time Protocol, es el protocolo de sincronizacin de relojes ms extendido en Internet. Fue creado en 1991 y basa su funcionamiento en el anlisis estadstico de los tiempos de retardo as como en la redundancia. Escucha por el puerto 119 y se utiliza actualmente en la mayora de los SOs

Algoritmo de Lamport
Fue ideado en 1978 y basa su funcionamiento en la premisa que es prcticamente imposible sincronizar relojes fsicos. El funcionamiento de este algoritmo est basado en la causalidad fsica: Cuando ocurren dos eventos estos ocurren en el orden en que se observan.

2.2.3 Usos de la sincronizacin

La sincronizacin de procesos distribuidos tiene una infinidad de aplicaciones a continuacin se muestran los principales usos.

Manejo de Cach
La cach es un rea de memoria utilizada para agilizar los procesos de lectura-escritura. El ejemplo ms conocido es la cach de los servidores Proxy Web, los cuales almacenan las pginas visitadas por los usuarios. As cuando un cliente pide una pgina, se revisa si est en la cache agilizando la navegacin y reduciendo el ancho de banda.

Exclusin Mutua
La exclusin mutua garantiza que slo un proceso est en una regin crtica. La exclusin mutua en sistemas distribuidos basa su funcionamiento en variantes de sistemas centralizados. Cuando un proceso distribuido desea entrar a una regin crtica debe de enviar la solicitud a todos los dems procesos recibiendo respuestas de todos.

Exclusin Mutua
Si otro proceso hace la solicitud al mismo tiempo se tomar como criterio de desempate la marca de tiempo o prioridad. Existen varias formas de exclusin mutua

Exclusin mutua en anillo: similar al manejo de redes con topologa fsica y lgica en anillo (TokenRing, TokenBus) teniendo un mensaje especial llamada token para poder entrar a la seccin crtica.

Exclusin Mutua en Anillo

Algoritmos de Eleccin
Una forma ms sencilla de llevar acabo la sincronizacin es a travs de la eleccin de un coordinador encargado de centralizar la decisin de dar acceso a la regin crtica.

Existen varios algoritmos. Entre ellos el del granduln. Este algoritmo consiste en que un proceso enva la solicitud si nadie responde se convierte en coordinador, si varios responden ser coordinador aquel que tenga mayor prioridad.

Algoritmo de Eleccin en Anillo

Los procesos se ordenan en forma jerrquica.

Cuando un proceso detecta un fallo, enva un mensaje a los dems, cada nodo empieza a destapar su candidatura, al regresar el token al nodo origen se determina quien gan y se distribuye el mensaje

Transacciones atmicas
Un esquema para garantizar la adecuada sincronizacin de la informacin en sistemas centralizados como distribuidos son el uso de transacciones.

Las transacciones manejan 4 propiedades bsicas: atmicas, consistentes, aisladas y durables (ACID por sus siglas en ingls).

Bitcoras
Para el manejo de transacciones se suele utilizar bitcoras. Las bitcoras llevan el registro de las operaciones realizadas y permiten dos operaciones bsicas: deshacer y rehacer operaciones. Se suele utilizar la tcnica de compromiso de dos fases para garantizar el correcto funcionamiento de las transacciones.

Transacciones
Otro de los problemas que presentan las transacciones son el manejo de concurrencia. Para solucionar este problema se utilizan algunas tcnicas como la cerradura, optimista y marcas de tiempo. En el mtodo de cerradura, el proceso debe bloquear el recurso y liberarlo una vez que halla finalizado el proceso.

Control Optimista
En este mtodo consiste en no preocuparse por la validacin de lo que realizan las transacciones de manera tan persistente. Si llegar a existir un problema de concurrencia con otro proceso que modific la misma informacin entonces se procede a deshacer la operacin.

Interbloqueo
Surge cuando un proceso busca el recurso ocupado por otro proceso y a su vez este proceso busca otro recurso, formado una cadenita que al final se cierra, por lo cual ningn proceso puede avanzar. Se manejan variantes de algoritmos centralizados para tratar de detectar, prevenir y eliminar interbloqueos.

Interbloqueo
Una forma de evitar interbloqueos es a travs de la replicacin de recursos. El problema radica en si los recursos son modificados, la informacin iene que ser reintegrada en las dems rplicas.

Nominacin
En los sistemas distribuidos los nombres hacen referencia a cualquier entidad, ya sea un archivo, un perifrico, un proceso, etc. que se pueden encontrar en mquinas remotas.

Los servidores de nombres ayudan a localizar fcilmente y hacer transparente el acceso a los recursos (transparencia de localizacin).

Nombres
Los servidores de nombre ayudan a simplificar el acceso a los recursos al tener un identificador fcil de recordar como un nombre propio, a tener una direccin numrica.

Uno de los servicios de nombres ms famosos es DNS (Domain Name Service) el cual mapea direcciones IP a nombres alfanumricos.

2.3.1 Caractersticas y estructuras

Un nombre es ms que una cadena de caracteres. Representa un punto de acceso hacia un objeto.

La caracterstica principal de un sistema de nombre es que no debe de presentar ambigedades, para un momento dado, un nombre refiere a uno y slo un recurso en el sistema.

Caractersticas de la nominacin
Los nombres pueden enfocarse a ser ms simples de localizar o a ser ms entendibles por los humanos. Los sistemas de nombres deben de ser capaces de localizar al mismo objeto independiente de su ubicacin. Los sistemas de nombres deben de proporcionar sistemas de comunicacin accesibles para todos los procesos.

Caractersticas de la nominacin
Los sistemas de nombres deben de almacenarse en un repositorio de datos proveyendo interfaces de acceso. Otro nombre que reciben los servicios de nominacin son los servicios de directorios. Los cuales permiten compartir informacin entre diferentes entidades en diferentes directorios (LDAP, X.500, Active Directory, etc.)

2.3.2 Tipos de nombres

Los nombres pueden ser absolutos o relativos dependiendo si la direccin a la cual estn asociada se realiza de manera directa o bien a partir de la ubicacin actual.

Los nombres pueden tener alias, los cuales son otros nombres con los cuales se referencia al mismo objeto.

Tipos de Nombres
Los nombres tambin pueden ser de usuario o de sistema. Son de usuario cuando ste les asocia un identificador a un objeto. Son de sistema aquellos que el sistema operativo le asigna internamente a un objeto de usuario.

2.3.3 Resolucin y distribucin

La resolucin es el proceso de convertir un nombre hacia la ubicacin real del recurso. La distribucin es el proceso por el cual un nombre puede difundirse a travs de todo el sistema y ser reconocido por cualquier entidad en cualquier momento.

2.3.4 Servidores y agentes de nombres

Los agentes de nombres son los procesos que permiten actualizar el repositorio de datos con los nombres y la ubicacin de cada uno de los recursos en la red.

2.3.5 Mapeo de direcciones

El mapeo de direcciones corresponde en la relacin de equivalencia entre un tipo de nombre a otro tipo de nombre; por ejemplo, de un nombre de usuario a un nombre de sistema.

Buscar la ruta alternativa para encontrar un recurso en la red Transformar las originales en alternativas y viceversa.

2.3.6 Mapeo de rutas

El mapeo de rutas consiste en la relacin de equivalencia entre un tipo de ruta u otro tipo. Recordar que las rutas consiste en la serie de ubicaciones para poder acceder a un recurso. Otro nombre que recibe el mapeo de rutas es el de encaminamiento.

2.3.7 Modelo de Terry

El problema principal de cualquier sistema de nombre reside en encontrar de manera fcil, sencilla y rpida cualquier recurso a travs del identificador (nombre) dado.

Para solucionar este problema, Terry y otros propusieron un modelo de facilidades que debe de poseer todo sistema de nombres, dichas caractersticas son las siguientes:

Modelo de Terry
Facilidad centralizada de nombramiento Facilidad replegada de nombramiento Facilidad descentralizada de nombramiento Facilidad distribuida de nombramiento Facilidad jerrquica de nombramiento.

A continuacin se muestra el caso de ejemplo de un sistema de nombres: el DNS

Nombres
DNS se origin para sustituir el viejo esquema de almacenar los nombres de las mquinas en un archivo (/etc/hosts). Actualmente existen diversas variantes de DNS como el DDNS o DNS dinmico.

Procesos como portmap, rmiregistry, orbd y UDDI se les considera servidores de nombres.

Nombres
Las operaciones ms comunes con los servidores de nombres son la resolucin (obtencin del nombre real a partir del abstracto) y la resolucin inversa (obtencion del nombre abstracto a partir del real). Se puede utilizar el comando lookup o dig para hacer la resolucin de nombres en sistemas DNS.

Nombres
Los nombres deben ser nicos y mantener una nomenclatura estndar. En el sistema DNS se utiliza dominios raiz (.com, .net, .org, etc.) y dominios locales (.mx, .it, .cl, etc.) Esto forma una jerarqua de dominios y subdominios. Los recursos pueden ser movibles, por lo que el servicio de nombres debe actualizarse

Nombres
Se recomienda que los servidores de nombres sean jerrquicos, descentralizados, con duplicacin de contenidos y redundantes.
En general, el esquema de nombres de Internet viene dado por las URI: Protocolo://maquina.dominio/recurso?param entros

Nombres

Nombres