UNIDAD 2

Comunicación en los Sistemas Operativos Distribuidos

2.1 Comunicación SOD

Para lograr la distribución de procesos se requiere de mecanismos que permitan coordinar y controlar la ejecución de procesos en ambientes no centralizados, ya sean de manera local y remota.

Los primeros protocolos para la distribución de procesos remotos fueron para máquinas homogéneas
Otra forma de comunicación fue la estandarización de sistemas heterogéneos con interfaz común UUCP (Unix to Unix Copy Protocol) que dio origen a los comandos R (rcopy, rlogin, rsh).

La comunicación entre procesos (IPC) es parte fundamental de las primitivas de sincronización de un sistema distribuido.
Los mecanismos de comunicación entre procesos no sólo aplican a aplicaciones distribuidas sino a cualquier tipo.

El mecanismo de comunicación entre procesos más famosos es el IPC (Inter Process Comunication) de Unix System V.
El otro punto a tratar es sobre los mecanismos de intercomunicación entre entidades de procesamiento diferentes con diferentes sistemas operativos: POSIX.

2.1.1 Comunicación Sockets

Los sockets son el mecanismo de sincronización distribuida más importante.
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 eléctrico con su respectivo zócalo

El mecanismo de sockets más conocido es el referente a la API de Berkeley.
Está API está implementado en prácticamente todos los sistemas Unix, por lo que se maneja C, pero también está portado a otras arquitecturas como Windows (WinSock) y a otros lenguajes como Java
Los sockets trabajan sobre capa 4 (Transporte) del modelo OSI, aunque algunos autores la ubican en la capa 5 (Sesión).
Para la comunicación de procesos remotos se necesita conocer la dirección de la máquina destino y el puerto donde se va a escuchar

2.1.2 COMUNICACIÓN RPC

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

El problema del manejo de procesos distribuidos con sockets radica en que se basa en el flujo de E/S, haciendo los programas más difíciles de estructurar.
En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).

El nivel de transparencia en RPC es muy alto ya que el usuario no tiene que ver con detalles de conexión.
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.
Para la transferencia de datos entre los stubs, se necesita de un proceso de empacar desempacar los parámetros y resultados. Dicho proceso recibe el nombre de marshalling.
Los stubs se comunican con los núcleos de cada proceso logrando una transparencia muy alta

2.1.3 Comunicación en Grupo

Se define a un grupo como un conjunto de procesos que actúan entre ellos encierto sistema.

Los grupos son dinámicos, ya que pueden aceptar nuevos procesos o estos pueden dejar a su grupo.

Los grupos pueden ser abiertos o cerrados dependiendo de cómo es el paso de mensajes entre los elementos del grupo.
Una de las mayores problemáticas con respecto a la comunicación en Sistemas Distribuidos es la forma en como podemos comunicar varios procesos distribuidos a la vez.

La comunicación tradicional es del tipo puntual (unicast) o bien hacia todos con el uso de la difusión (broadcast). El problema radica en que al hacer un broadcast los mensajes llegan hacia todas las máquinas 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 técnica de multicast.

2.1.4 Tolerancia a fallos

La tolerancia a fallas es considerada la principal característica que debe de tener un sistema distribuido para alcanzar el principio de transparencia.
Para lograr la tolerancia a fallos se necesita de una buena comunicación entre procesos distribuidos y sobretodo de una correcta coordinación entre procesos

Un Sistema Distribuido en base a la coordinación de sus procesos puede ser:

Asíncrono: no hay coordinación en el tiempo.
Síncrono: se suponen límites máximos para el retraso de mensajes.

El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable).
Para garantizar que el canal sea confiable se debe de realizar lo siguiente:

Retransmisión de mensajes.
Debe haber redundancia de canales
La entrega de un paquete sea dentro de un tiempo límite especificado

En general, se considera que los canales de comunicación son fiables y que cuando falla la comunicación es debido a la caída del proceso.
Las fallas de partición son las fallas de comunicación más importantes ya que fragmentan la red en pequeñas áreas llamadas particiones haciendo imposible el manejo de la consistencia de los datos.
Son difíciles de detectar ya que no son visibles para todos los nodos de la red.

2.2 Sincronización en los Sistemas Distribuidos

La sincronización de procesos en los sistemas distribuidos resulta más compleja que en los centralizados, debido a que la información y el procesamiento se mantiene en diferentes nodos.
Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos.
Sincronización es la forma de forzar un orden parcial o total en cualquier conjunto de evento
Se utilizan algoritmos distribuidos para sincronizar el trabajo común entre los procesos y estos algoritmos tienen las siguientes propiedades:
inaceptable que se concentre en un nodo, a toda la información y procesamiento