2.1 Llamada a procedimiento remoto (RPC)
En el anterior epígrafe hemos estudiado un modelo de interacción entre los procesos de un sistema distribuido que es el modelo cliente-servidor. Para implementarlo, el sistema dispone de dos llamadas al sistema, send y receive, que las aplicaciones utilizan de forma conveniente. Estas primitivas, a pesar de constituir la base de la construcción de los sistemas distribuidos, pertenecen a un nivel demasiado bajo como para programar de forma eficiente aplicaciones distribuidas.
2.1.1 La operación RPC básica
La llamada a procedimiento remoto constituye un mecanismo que integra el concepto cliente-servidor con la programación convencional basada en llamadas a procedimientos. La idea surgió en 1984 y consiste en que el cliente se comunica con el servidor mediante una llamada ordinaria a un procedimiento. Esta llamada se denomina a procedimiento remoto porque el procedimiento invocado se encuentra en otro espacio de direccionamiento, en la misma o en distinta máquina que el cliente. La información se transporta en los parámetros de la llamada y el resultado es devuelto en el retorno de la llamada. El cliente no tiene que utilizar las primitivas send y receive como en el modelo cliente-servidor puro, de modo que la programación de aplicacio-nes distribuidas se hace más sencilla.
La figura 2.7 muestra un ejemplo del uso de RPC. El cliente necesita de un servicio que es la suma de dos enteros. El servicio se invoca mediante a una llamada a función tal y como se hace en un programa convencional escrito en C. La única diferencia es que la función se ejecuta en una máquina diferente de una forma completamente transparente al usuario.
La función suma(2, 3); de la figura se implementa en el cliente como una rutina de biblioteca que se denomina el cabo o “stub” cliente. Recordemos cómo se implementan las llamadas al sistema en un lenguaje como C en un sistema operativo centralizado. Estas acaban almacenando los parámetros de la llamada en los registros de la CPU y ejecutando una instrucción de trap al sistema operativo. En un sistema distribuido las cosas son básicamente iguales. La función suma contiene una llamada al sistema send seguida de una llamada receive, donde el programa cliente que invoca suma(2, 3); es suspendido hasta que llega la respuesta del servidor, según el modelo de interacción cliente-servidor. Como podemos ver, el mecanismo RPC no es sino el modelo cliente-servidor, pero con una interfaz más sencilla que hace que el cliente invoque al servicio por su nombre y sin necesidad de gestionar números de puerto.
En cuanto al servidor, el cabo no es una función como era suma en el cliente, sino que es el programa principal. El programador del servicio sólo se ocupa del procedimiento que invoca el cliente. Las llamadas de receive y send en el servidor son ejecutadas por el cabo, que recibe el mensaje, determina el procedimiento solicitado -suma en este caso- y, finalmente, lo invoca. Todos los pasos implicados son los siguientes:
1. El cliente llama al cabo cliente en la manera convencional. 2. El cabo cliente construye un mensaje empaquetando los parámetros del procedimiento y salta al kernel mediante un trap. 3. El kernel local envía el mensaje al kernel remoto. 4. El kernel remoto entrega el mensaje al cabo servidor. 5. El cabo servidor desempaqueta los parámetros y llama al procedimiento de servicio. 6. El procedimiento de servicio hace el trabajo y devuelve el resultado. 7. El cabo servidor empaqueta el resultado y salta al kernel mediante un trap. 8. El kernel remoto envía el mensaje al kernel local. 9. El kernel local envía el mensaje al cabo del cliente, ahora suspendido esperándolo. 10. El cabo local desempaqueta el resultado y lo devuelve al cliente.
2.1.2 El paso de parámetros
La función del cabo cliente es empaquetar los parámetros en un mensaje y enviarlo al cabo servidor. Este examina el código del procedimiento en una sentencia tipo switch e invoca el procedimiento de forma local. El resultado es de nuevo empaquetado en un mensaje y enviado al cabo cliente. Esta interacción, que parece directa, no es tan simple como aparenta ser. Mientras las arquitecturas del cliente y del servidor sean iguales no se presenta ningún problema especial. En un entorno distribuido, sin embargo, cada arquitectura tiene su propia representación de números, caracteres, etc. Por ejemplo, los mainframe IBM utilizan el código EBCDIC para los caracteres en lugar del código ASCII, como el IBM PC. Problemas similares ocurren con la representación de coma flotante o los enteros negativos (complemento a 1 o complemento a 2).
Comunicación con los clientes-Servidor (Socket)
Origen de los socket tuvo lugar en una variante del sistema operativo Unix conocida como BSD Unix. En la universidad de Berkeley, en los inicios del Internet, pronto se hizo evidente que los programadores necesitarían un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre sí. Esta necesidad dio origen a la primera especificación e implementación de sockets.
Cliente-Servidor es el modelo que actualmente domina el ámbito de comunicación, ya que descentraliza los procesos y los recursos. Es un Sistema donde el cliente es una aplicación, en un equipo, que solicita un determinado servicio y existe un software, en otro equipo, que lo proporciona.
Los servicios pueden ser;
a)Ejecución de un programa. b)Acceso a una Base de Datos. c)Acceso a un dispositivo de hardware.
Solo se requiere un medio físico de comunicación entre las maquinas y dependerá de ala naturaleza de este medio la vialidad del sistema.
Definición de Socket: designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo de datos, generalmente de manera fiable y ordenada.
Los sockets proporcionan una comunicación de dos vías, punto a punto entre dos procesos. Los sockets son muy versátiles y son un componente básico de comunicación entre interprocesos e intersistemas. Un socket es un punto final de comunicación al cual se puede asociar un nombre.
Para lograr tener un socket es necesario que se cumplan ciertos requisitos
1.Que un programa sea capaz de localizar al otro. 2.Que ambos programas sean capaces de intercambiarse información.
Por lo que son necesarios tres recursos que originan el concepto de socket
a)Un protocolo de comunicaciones, que permite el intercambio de octetos.
b)Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
c)Un número de puerto, que identifica a un programa dentro de una computadora. Con un socket se logra implementar una arquitectura cliente-servidor. la comunicación es iniciada por uno de los programas (cliente). Mientras el segundo programa espera a que el otro inicie la comunicación (servidor). Un Socket es un archivo existente en el cliente y en el servidor.
si un socket es un punto final de un puente de comunicaron de dos vías entre dos programas que se comunican a través de la red, ¿Cómo funciona?. Normalmente, un servidor funciona en una computadora específica usando un socket con un número de puerto especifico. El cliente conoce el nombre de la maquina (hostname) o el IP, en la cual el servidor esta funcionando y el numero del puerto con el servidor esta conectado.
Si el cliente lanza una demanda de conexión y el servidor acepta la conexión, este abre un socket en un puerto diferente, para que pueda continuar escuchando en el puerto original nuevas peticiones de conexión, mientras que atiende a las peticiones del cliente conectado. El cliente y el servidor pu8eden ahora comunicarse escribiendo o leyendo en sus respectivos sockets.
Comunicacion en Grupo
La comunicación se clasifica deacuerdo al numero de usuarios alos que se le a enviado el mensaje.
-BROADCAST O DIFUSION FORZADA un nodo emite todos los escuchan y solo contesta a quien va dirigido el mensaje
-MULTICAST se entrega el msj a todos los anfitriones HOST que están compuestos de ciertas características.
-UNICAST o POINTCAST un nodo emite y otro recibe, solo escucha aquel a quien se dirigió el msj.
Una clasificación adicional es la realizada en base a grupos
-LISTAS DE DESTINARIOS se tiene una lista de aquellos alos que se les enviara el mensaje.
-IDENTIFICADOR DE GRUPO se forman grupos y el msj es dirigido solo a los miembros de ese grupo.
-PREDICADOR DE PERTENENCIA se envía y otro recibe, solo escucha aquel a quien se dirigió el mensaje.
Relojes Físicos
El algoritmo de Lamport proporciona un orden de eventos sin ambigüedades, pero [25, Tanenbaum]:
Los valores de tiempo asignados a los eventos no tienen porqué ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj: Se precisan relojes físicos externos (más de uno). Se deben sincronizar: Con los relojes del mundo real. Entre sí. La medición del tiempo real con alta precisión no es sencilla. Desde antiguo el tiempo se ha medido astronómicamente.
Se considera el día solar al intervalo entre dos tránsitos consecutivos del sol, donde el tránsito del sol es el evento en que el sol alcanza su punto aparentemente más alto en el cielo.
El segundo solar se define como 1 / 86.400 de un día solar.
Como el período de rotación de la tierra no es constante, se considera el segundo solar promedio de un gran número de días.
Los físicos definieron al segundo como el tiempo que tarda el átomo de cesio 133 para hacer 9.192.631.770 transiciones:
Se tomó este número para que el segundo atómico coincida con el segundo solar promedio de 1958. La Oficina Internacional de la Hora en París (BIH) recibe las indicaciones de cerca de 50 relojes atómicos en el mundo y calcula el tiempo atómico internacional (TAI). Como consecuencia de que el día solar promedio (DSP) es cada vez mayor, un día TAI es 3 mseg menor que un DSP:
La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase: El sistema de tiempo basado en los segundos TAI. El movimiento aparente del sol. Surge el tiempo coordenado universal (UTC). El Instituto Nacional del Tiempo Estándar (NIST) de EE. UU. y de otros países: Operan estaciones de radio de onda corta o satélites de comunicaciones. Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.). Se deben conocer con precisión la posición relativa del emisor y del receptor: Se debe compensar el retraso de propagación de la señal. Si la señal se recibe por módem también se debe compensar por la ruta de la señal y la velocidad del módem. Se dificulta la obtención del tiempo con una precisión extremadamente alta.
Reloj Logico
Es un cronómetro consistente en un cristal de cuarzo de precisión sometido a una tensión eléctrica que:
- Oscila con una frecuencia bien definida que depende de:
o Al forma en que se corte el cristal.
o El tipo de cristal.
o La magnitud de la tensión.
- A cada cristal se le asocian dos registros:
o Registro contador.
o Registro mantenedor.
- Cada oscilación del cristal decrementa en “1” al contador.
- Cuando el contador llega a “0”:
o Se genera una interrupción.
o El contador se vuelve a cargar mediante el registro mantenedor.
- Se puede programar un cronómetro para que genere una interrupción “x” veces por segundo.
- Cada interrupción se denomina marca de reloj.
Para una computadora y un reloj:
- No interesan pequeños desfasajes del reloj porque:
o Todos los procesos de la máquina usan el mismo reloj y tendrán consistencia interna.
o Importan los tiempos relativos.
Programa
struct sockaddr
{
unsigned short sa_family; // AF_*
char sa_data[14]; // Direccion de
protocolo.
};
struct sockaddr_in
{
short int sin_family; // AF_INET
unsigned short sin_port; // Numero de puerto.
struct in_addr sin_addr; // Dirección IP.
unsigned char sin_zero[8]; // Relleno.
};
struct in_addr
{
unsigned long s_addr; // 4 bytes.
};
