Tabla de contenidos RPC

4.11 NCS("Network Computing System")

Figura: NCS("Network Computing System")

El NCS de APOLLO es una implementación de la NCA ("Network Computing Architecture") desarrollada con el fin de proporcionar herramientas para diseñar, implementar y dar soporte para aplicaciones que requieran datos y computación distribuidos. Esto se consigue mediante implementaciones de NCS sobre la interfaz de RPC, que es diferente del RPC de Sun.

El NCS está orientado a objetos. Esto permite a los programas acceder a los objetos a través de interfaces con independientemente de las máquinas con las que se comunican. Estos tipos de programas tienen un diseño más simple y son menos susceptibles frente a cambios en el hardware o en la red.

Un objeto es una entidad gestionada por operaciones definidas que tienen un tipo especificador de la clase. Por ejemplo, un fichero de disco es un objeto y puede ser de tipo ASCII.

Una interfaz es un conjunto de operaciones que manipulan los objetos.

El NCA emplea un concepto expandido llamado objetos replicados que son copias de un objeto que tienen el mismo identificador. Puede ser débilmente consistente o fuertemente consistente. Los objetos replicados débilmente consistentes pueden ser accedidos aunque no sean idénticos. Los objetos replicados fuertemente consistentes sólo pueden ser accedidos cuando son idénticos. El uso de un tipo u otro de objetos depende de los requerimientos de rendimiento, disponibilidad y consistencia.

Los datos y el procesamiento distribuidos se obtienen gracias al uso de los siguientes componentes:

1. La librería "runtime" de RPC("Remote Procedure Call")
2. El compilador de NIDL("Network Interface Definition Language")
3. El Location Broker

El NCK("Network Computing Kernel") consiste en el Location Broker y la librería "runtime" de RPC, que suministra apoyo en tiempo de ejecución a la computación distribuida. Este kernel(NCK) y el compilador son la base para el desarrollo e implementación de aplicaciones distribuidas.

4.11.0.1 NCS RPC

El NCS RPC puede utilizar los protocolos de comunicaciones de dominios de red("Domain network communications protocols(S)") y los protocolos de Internet de DARPA(UDP/IP). La selección se hace en función de la dirección de destino de tal forma que un programa puede acceder o no a un dominio.

El NCS RPC maneja el concepto de zócalo de Berkeley. Puede atender a más de un zócalo identificado por un dirección de zócalo dividida en familia de direcciones (que define la estructura de la dirección), dirección de red(dirección del host) y número de puerto(dirección de destino final).


Figura: componentes de NCS

El procedimiento cliente usa convenios estándar de llamada a procedimientos, pero es ejecutado remotamente por el servidor. El programa que realiza llamadas remotas a procedimientos es el cliente RPC. No tiene idea de cómo se implementa la interfaz y puede que no conozca la dirección del servidor.

El proceso que recibe el paquete de solicitud de la operación de la librería "runtime" de RPC es el servidor RPC. Es responsable de enviar la respuesta con los resultados de la operación. Un servidor puede exportar una interfaz para más de un objeto.

El proceso cliente tiene tres componentes: el procedimiento cliente que hace llamadas, el "stub" del cliente y la librería "runtime" de RPC. El "stub" del cliente es el encargado de usar la librería "runtime" de RPC para hacer que se ejecuten las llamadas del cliente.

El proceso servidor tiene tres componentes: los procedimientos de gestión correspondientes a la aplicación cliente, el "stub" del servidor correspondiente al del cliente y la librería "runtime" de RPC. El servidor puede denominarse gestor o manager.

Cuando el cliente solicita una operación en un objeto concreto a través de RPC, debe indicar el objeto sobre el que se va a efectuar, así como el servidor que exporta la interfaz que contiene esa operación. Esta información se pasa mediante un manejador o "handle", creado y gestionado por varias llamadas que proporciona NCS. La representación del servidor en el manejador se denomina liga o enlace("binding"). El cliente puede crear o no una liga en el manejador solicitando un RPC con los siguientes estados:

• Unbound(desligado) - sin identificación(RPC hace un broadcast a todos los host en la red local y acepta la primera respuesta).
• Bound-to-host(ligado al host) - el manejador contiene identificación del host pero sin especificar un servidor(se envía un RPC al host y el Location Broker local encuentra el puerto correcto).
• Bound-to-server(ligado al servidor) - el manejador contiene la identificación completa(el RPC se envía al puerto específico el servidor).

Los "stubs" son responsables de que la llamada remota sea lo más transparente posible. Hacen de intermediarios entre el cliente y los procedimientos de gestión, convirtiendo datos para el uso de las rutinas de la librería "runtime" de RPC.

Esta librería transmite paquetes RPC que contienen rutinas, tablas y datos para apoyar la comunicación entre el cliente y el "stub" del servidor. Hay tres tipos de llamadas:

• Llamadas del cliente usadas para operar con los manejadores y enviar paquetes.
• Llamadas del servidor usadas para crear zócalos, registrar interfaces y devolver identificaciones de objetos.
• Llamadas de conversión usadas para determinar la dirección del zócalo de un host determinado y devolver el nombre del host y número de puerto para ese zócalo.

4.11.0.2 NIDL("Network Interface Definition Language")

El NIDL es un lenguaje de desarrollo que define por completo la interfaz y los parámetros de cada RPC. Se usan dos sintaxis, una más cómoda para programadores en C, y otra para programadores en PASCAL.

El compilador NIDL traduce los comandos NIDL a "subs" ejecutables que serán enlazados con clientes y servidores. Estos "stubs" se generan en código fuente de C pero son totalmente compatibles con los programas de PASCAL.


Figura: compilador NIDLr - Ficheros generados.

El compilador NIDL genera dos ficheros "stub" para el cliente: name_cstub.c y name_cswtch.c. El segundo es un fichero que hace de conmutador; se emplea para crear servidores replicados que den acceso a objetos replicados y aseguren consistencia. Las llamadas del cliente se envían al conmutador que contiene los procedimientos públicos, dejando en el "stub" del cliente sólo los privados.

El "stub" generado puede tener dos responsabilidades principales:

• Copiar y convertir datos - Los "tubs" más simples tienen sólo un procedimiento para el paso de argumentos y la conversión de datos. Todos los "stubs" ordenan y recuperan datos en y desde el paquete RPC. El "stub" del cliente ordena los parámetros de entrada para enviar el paquete al servidor y recupera los parámetros de salida del paquete de respuesta. El "stub" del servidor recupera los parámetros de entrada del paquete RPC del cliente y los envía al manager de la interfaz, y ordena los parámetros de salida para enviárselos al cliente. Además, cada "stub" chequea el formato indicado de los datos en el paquete transmitido. Cada sistema envía datos en su formato nativo y el "stub" los convierte a la representación del receptor. Es importante notar que ningún "stub" envía datos en un formato estándar de modo tal que, si ambos sistemas usan la misma representación de los datos, no hay necesidad de convertirlos.
• Liga con una interfaz remota - NIDL gestiona el objeto y la información de la liga de las siguientes formas:
• Manejador explícito - el cliente pasa explícitamente el manejador como parámetro en cada operación pasada a las rutinas de gestión del servidor.
• Manejador implícito - el manejador es una sola variable global que hace que el RPC se parezca más a una llamada a un procedimiento corriente aunque la restringe a un sistema con un sólo servidor.
• Liga manual - el cliente hace todas las llamadas para crear y gestionar el manejador.
• Liga automática - el cliente llama a una rutina de ligamiento automática para cada RPC, y a una rutina de desligamiento tras recibir la respuesta, cambiando así rendimiento por eficiencia.

4.11.0.3 El Location Broker

El Location Broker es usado por el cliente para solicitar información sobre objetos e interfaces. Los servidores registran esta información en el Location Broker.

El Location Broker se componen de tres elementos:

• Location Broker Local(LLB) - mantiene información sobre objetos e interfaces en el host local y se la suministra a programas de aplicación locales o remotos. También le da al cliente la capacidad de envío del LLB, que evita que un cliente tenga que conocer el puerto específico usado por el servidor.
• Location Broker Global(GLB) - mantiene información sobre objetos e interfaces en toda la red.
• Agente del Cliente del Location Broker - se trata de un conjunto de rutinas llamadas por programas de aplicación para acceder las bases de datos del LLB y el GLB. El cliente puede conocer el host en el que se localiza el objeto e interrogar directamente al LLB del host remoto; de otro modo, tendría que usar el GLB.

El GLB puede tener varias réplicas ejecutándose para asegurar la disponibilidad de la información. Para garantizar la consistencia de los datos de las réplicas, el DRM("Data Replication Manager") se encarga de toda la manipulación, propagando cualquier cambio en la base de datos. El DRM maneja una lista de réplicas que contiene la localización de cada réplica. A los clientes se les permite bloquear el acceso a los objetos y actualizarlos, lo que debilita la consistencia, pero mejora la disponibilidad.

La base de datos del Location Broker tiene los siguientes campos:

• Object UUID - identificador del objeto
• Type UUID - tipo del identificador del objeto
• Interface UUID - interfaz del identificador del objeto
• Flags - indicación de un objeto global
• Annotation - definida por el usuario
• Socket address length - longitud de la dirección del zócalo
• Socket address - localización del servidor

Aquí hay algunas definiciones:

• UUID significa Identificador Universal Unívoco ("Universal Unique IDentifier"), es decir, un valor de 128 bits usado para la identificación. Ningún otro objeto, tipo o interfaz puede hacer uso de un UUID que ya ha sido asignado.
• Objeto: entidad manipulada por operaciones bien conocida. Ficheros de disco e impresoras son ejemplos de objetos. Las interfaces son el medio de acceso a los objetos. Todo objeto tiene un tipo.
• Tipo: un clase de objeto. Se puede acceder a todos los objetos del mismo tipo específico a través de la misma interfaz o interfaces.
• Interfaz: conjunto de operaciones. El NCA especifica un Lenguaje de Definición de Interfaz de Red("Network Interface Definition Language(NIDL)") para definir interfaces.
• NIDL: lenguaje declarativo para la definición de interfaces.
• Compilador NIDL: herramienta NCS que convierte la definición de una interfaz, escrita en NIDL, en varios módulos de programa, que incluyen código fuente para los "stubs" del cliente y del servidor.

Tabla de contenidos NFS ("Network File System(NFS)")