Comunicación

en Ambientes
Distribuidos

Algoritmos
Concurrentes y
Paralelos

1
 1. Comunicación en ambientes
distribuidos
En los sistemas distribuidos, la comunicación se realiza a través de
transferencia de mensajes. Esto se debe a la ausencia de memoria
compartida.
Un mensaje es la información que pasa de un proceso de remitente a un
El paso de mensajes es
proceso de destinatario.
una técnica para
invocar Cuando un proceso A quiere emitir un mensaje hacia el proceso B,
comportamientos (es destinatario, debe realizar las siguientes tareas:
decir, ejecutar un
programa) en una  el proceso A, en su propio espacio de direcciones construye, un
computadora. El mensaje;
programa de
invocación envía un
 el proceso A ejecuta una llamada al sistema operativo para que
mensaje a un proceso busque el mensaje y lo envíe hacia el proceso B a través de la red.
(que puede ser un
actor u objeto) y se Los procesos A y B deben interpretar de la misma forma el significado de los
basa en el proceso y la bits que se envían. Se deben acordar los siguientes aspectos para lograr esta
infraestructura de
soporte para
interpretación común:
seleccionar e invocar
el código real para  Aspectos físicos: la cantidad de voltios que hay que utilizar para un
ejecutar. bit 0 y para un bit 1.
 Aspectos lógicos: indicación para el receptor sobre cuál es el último
bit del mensaje.
 Detección y corrección de errores: acuerdo sobre cómo se puede
detectar si un mensaje ha sido dañado o perdido y qué debe hacer
cuando se descubre un mensaje dañado o perdido.
 Estructuras y representación de datos iguales: la longitud que
tienen los números, cadenas y otros elementos de datos y cuál es la
forma en que están representados.

2
2. Modelo OSI
El desarrollo de las redes ha sido vertiginoso y desordenado. Debido a las
diferentes especificaciones o implementaciones que se realizaron, en cierto
momento se encontraron con la dificultad de la incompatibilidad entre las
distintas redes.
Para enfrentar este problema, en el año 1980, la Organización Internacional
de Estandarización, conocida como ISO, planteó el modelo de interconexión
de sistemas abiertos (ISO-IEC 7498-1), también conocido como modelo OSI
(por sus siglas en inglés, open system interconnection). Fue publicado en
1983 por la Unión Internacional de Telecomunicaciones (UIT) y en 1984 por
la ISO.
El modelo OSI es un modelo de referencia para los protocolos de la red de
arquitectura en capas. A su vez, facilita las comunicaciones porque les
proporciona un lenguaje común a los procesos que intervienen. Pero no
puede ser considerado una arquitectura, porque no especifica qué
protocolos deben ser usados en cada capa.

3
Figura 1: Modelo OSI

Fuente: Offnfopt, 2 de mayo de 2015, https://goo.gl/cbf5b4

El modelo OSI, en términos generales, presenta las siguientes características:

 se lo denomina modelo de referencia para interconexión de sistemas

abiertos (ISO, OSI o modelo OSI);
 está diseñado para permitir la comunicación de los sistemas abiertos
(son aquellos preparados para comunicarse con cualquier otro
sistema abierto mediante reglas estándar);
 identifica en forma clara los distintos niveles;
 estandariza los nombres de los niveles;
 señala para cada nivel qué trabajo debe realizar.

Los mensajes entre procesos se intercambian de formas diferentes, donde

hay muchas opciones de diseño. Una de esas opciones, tal vez la más

4
importante, es la conocida como procedimiento remoto. En esta opción se
tienen en cuenta las posibilidades de comunicación entre grupos de
procesos, además de la comunicación solo entre dos procesos.

3. Arquitecturas
Se utilizan diversas arquitecturas de hardware y software para la
computación distribuida. En un nivel inferior, es necesario interconectar
varias CPU (unidad central de proceso, por su nomenclatura en inglés central
processing unit) con algún tipo de red, independientemente de si esa red
está impresa en una placa de circuito o está formada por dispositivos y
cables acoplados libremente. En un nivel superior, es necesario
interconectar procesos que se ejecutan en esas CPU con algún tipo de
sistema de comunicación.
La programación distribuida generalmente cae en una de varias
arquitecturas básicas: cliente-servidor (client-server), de tres niveles (three-
tier), de nivel n (n-tier), de igual a igual (peer-to-peer), o bien en categorías
como acoplamiento suelto (loose coupling) o acoplamiento apretado (tight
coupling).
Otro aspecto básico de la arquitectura de computación distribuida es el
método de comunicación y coordinación del trabajo entre procesos
concurrentes. A través de varios protocolos de paso de mensajes, los
procesos pueden comunicarse directamente entre sí, generalmente en una
relación entre maestro y esclavo. Alternativamente, una arquitectura
centrada en la base de datos puede permitir que la computación distribuida
se realice sin ninguna forma de comunicación directa entre procesos
mediante la utilización de una base de datos compartida.

3.1. Cliente y servidor

El modelo cliente-servidor (client-server) es una estructura de aplicación
distribuida que divide las tareas o cargas de trabajo entre los proveedores
de un recurso o servicio, llamados servidores, y los solicitantes de servicios,
llamados clientes. A menudo, los clientes y los servidores se comunican a
través de una red de computadoras en un hardware separado, pero tanto el
cliente como el servidor pueden residir en el mismo sistema. Un servidor
ejecuta uno o más programas del servidor que comparte sus recursos con
los clientes. Un cliente no comparte ninguno de sus recursos, pero solicita el
contenido de un servidor o la función de servicio. Por lo tanto, los clientes
inician sesiones de comunicación con servidores que esperan solicitudes
entrantes. Algunos ejemplos de aplicaciones informáticas que utilizan el
modelo cliente-servidor son el correo electrónico, la impresión en red y el
servicio de páginas web.

5
Una característica importante del modelo cliente-servidor describe la
relación de los programas que cooperan en una aplicación. El componente
de servidor proporciona una función o servicio a uno o varios clientes, que
inician las solicitudes de dichos servicios. Los servidores están clasificados
por los servicios que prestan. Por ejemplo, un servidor web sirve páginas
web y un servidor de archivos sirve archivos de computadora. Un recurso
compartido puede ser cualquier software o componente electrónico de la
computadora del servidor, desde programas y datos hasta procesadores y
dispositivos de almacenamiento. En este contexto, se denomina servicio al
intercambio de recursos de un servidor.
Si una computadora es un cliente, un servidor o ambos, está determinada
por la naturaleza de la aplicación que requieren las funciones de servicio. Por
ejemplo, una sola computadora puede ejecutar el servidor web y el software
del servidor de archivos al mismo tiempo para proporcionar datos a los
clientes que realizan diferentes tipos de solicitudes. El software del cliente
también puede comunicarse con el software del servidor dentro de la misma
computadora. La comunicación entre servidores, como la sincronización de
datos, a veces se denomina comunicación entre servidores o de servidor a
servidor.
En general, un servicio es una abstracción de los recursos informáticos y un
cliente no tiene que preocuparse por el rendimiento del servidor mientras
cumpla con la solicitud y entregue la respuesta. El cliente solo tiene que
entender la respuesta basada en el protocolo de aplicación conocido, es
decir, el contenido y el formato de los datos para el servicio solicitado.
Los clientes y servidores intercambian mensajes en un patrón de mensajería
de solicitud-respuesta. El cliente envía una solicitud y el servidor devuelve
una respuesta. Este intercambio de mensajes es un ejemplo de
comunicación entre procesos.
Para comunicarse, las computadoras deben tener un lenguaje común y
deben seguir las reglas para que tanto el cliente como el servidor sepan qué
esperar. El lenguaje y las reglas de comunicación se definen en un protocolo
de comunicaciones. Todos los protocolos cliente-servidor operan en la capa
de aplicación (del modelo OSI). El protocolo de capa de aplicación define los
patrones básicos del diálogo. Para formalizar aún más el intercambio de
datos, el servidor puede implementar una interfaz de programación de
aplicaciones (API). La API es una capa de abstracción para acceder a un
servicio. Al restringir la comunicación a un formato de contenido específico,
facilita el análisis. Al abstraer el acceso, facilita el intercambio de datos entre
plataformas.

6
3.2. N niveles
La arquitectura multinivel (a menudo denominada arquitectura de N niveles)
o la arquitectura multicapa es una arquitectura cliente-servidor en la que las
funciones de presentación, procesamiento de aplicaciones y gestión de
datos están separadas físicamente. El uso más extendido de la arquitectura
de varios niveles es la arquitectura de tres niveles.
La arquitectura de aplicaciones de N niveles proporciona un modelo
mediante el cual los desarrolladores pueden crear aplicaciones flexibles y
reutilizables. Al segregar una aplicación en niveles, los desarrolladores
adquieren la opción de modificar o agregar una capa específica, en lugar de
volver a trabajar toda la aplicación. Una arquitectura de tres niveles
generalmente se compone de un nivel de presentación, un nivel de lógica de
dominio y un nivel de almacenamiento de datos.
Si bien los conceptos de capa (layer) y nivel (tier) se usan indistintamente,
efectivamente hay una diferencia. La diferencia se basa en que una capa es
un mecanismo de estructuración lógica para los elementos que conforman
la solución de software, mientras que un nivel es un mecanismo de
estructuración física para la infraestructura del sistema. Por ejemplo, una
solución de tres capas podría implementarse fácilmente en un solo nivel,
como una estación de trabajo personal.

3.3. Tres niveles

La arquitectura de tres niveles (three-tier architecture) es un patrón de
arquitectura de software cliente-servidor en el que la interfaz de usuario
(presentación), la lógica de proceso funcional (reglas de negocios), el
almacenamiento de datos informáticos y el acceso a datos se desarrollan y
mantienen como módulos independientes, generalmente en plataformas
separadas. Fue desarrollado por John J. Donovan en Open Environment
Corporation (OEC), una compañía de herramientas que fundó en Cambridge,
Massachusetts.
Además de las ventajas habituales del software modular con interfaces bien
definidas, la arquitectura de tres niveles está diseñada para permitir que
cualquiera de los tres niveles se actualice o reemplace de forma
independiente en respuesta a los cambios en los requisitos o la tecnología.
Por ejemplo, un cambio de sistema operativo en el nivel de presentación
solo afectaría el código de la interfaz de usuario.
Normalmente, la interfaz de usuario se ejecuta en una computadora de
escritorio o estación de trabajo y utiliza una interfaz gráfica de usuario
estándar, una lógica de proceso funcional que puede consistir en uno o más
módulos independientes que se ejecutan en una estación de trabajo o
servidor de aplicaciones, y un sistema de gestión de base de datos (o
RDBMS) en un servidor de base de datos o mainframe que contiene la lógica

7
de almacenamiento de datos de la computadora. El nivel medio puede ser
de varios niveles (en cuyo caso, la arquitectura general se denominaría
arquitectura de n niveles).
 Nivel de presentación: este es el nivel más alto de la aplicación. El
nivel de presentación muestra información relacionada con servicios
tales como la navegación de mercancías, la compra y el contenido
del carrito de compras. Se comunica con otros niveles mediante los
cuales distribuye los resultados al nivel de navegador o cliente y
todos los demás niveles de la red. En términos simples, es una capa
a la que los usuarios pueden acceder directamente (como una página
web o una GUI del sistema operativo).
 Nivel de aplicación (lógica empresarial, nivel lógico o nivel medio):
el nivel lógico se extrae del nivel de presentación y, como su propia
capa, controla la funcionalidad de una aplicación realizando un
procesamiento detallado.
 Nivel de datos: el nivel de datos incluye los mecanismos de
persistencia de datos (servidores de base de datos, recursos
compartidos de archivos, etc.) y la capa de acceso a datos que
encapsula los mecanismos de persistencia y expone los datos. La
capa de acceso a datos debe proporcionar una API al nivel de
aplicación que exponga los métodos de administración de los datos
almacenados, sin exponer o crear dependencias en los mecanismos
de almacenamiento de datos. Evitar dependencias en los
mecanismos de almacenamiento permite actualizaciones o cambios
sin que los clientes del nivel de la aplicación se vean afectados por el
cambio o que estén conscientes de él. Al igual que con la separación
de cualquier nivel, existen costos de implementación y, a menudo,
costos de rendimiento a cambio de una mejor escalabilidad y
mantenibilidad.

3.4. Entre pares (peer to peer)

La computación o la red entre pares (P2P o peer to peer) es una arquitectura
de aplicación distribuida que divide las tareas o cargas de trabajo entre
iguales. Los compañeros son participantes igualmente privilegiados,
equipotentes en la aplicación. Se dice que forman una red de nodos de igual
a igual.
Los pares usan una parte de sus recursos, como la capacidad de
procesamiento, el almacenamiento en disco o el ancho de banda de la red,
directamente disponibles para otros participantes de la red, sin la necesidad
de una coordinación central por parte de servidores o hosts estables. Los
pares son tanto proveedores como consumidores de recursos, en contraste
con el modelo tradicional de cliente-servidor en el que se divide el consumo

8
y el suministro de recursos. Los sistemas P2P de colaboración emergentes
van más allá de la era de los pares que hacen cosas similares al compartir
recursos. De ese modo, buscan pares diferentes que puedan aportar
recursos y capacidades únicas a una comunidad virtual, lo que le permite
participar en tareas más grandes que las que se pueden lograr con pares
individuales; sin embargo, son beneficiosos para todos los compañeros.

3.5. Acoplamiento suelto (loose coupling)

Un sistema de acoplamiento suelto (loose coupling) o acoplamiento flexible
es uno en el que cada uno de sus componentes tiene, o hace uso de, poco o
ningún conocimiento de las definiciones de otros componentes separados.
Las subáreas incluyen el acoplamiento de clases, interfaces, datos y
servicios. El acoplamiento suelto es lo opuesto al acoplamiento apretado.
Los componentes en un sistema de acoplamiento flexible pueden
reemplazarse con implementaciones alternativas que brindan los mismos
servicios. Los componentes en un sistema de acoplamiento flexible están
menos limitados a la misma plataforma, idioma, sistema operativo o
entorno de compilación.
Si los sistemas se desacoplan, es difícil proporcionar integridad transaccional
y son requeridos protocolos adicionales de coordinación. La replicación de
datos en diferentes sistemas proporciona un acoplamiento suelto
(disponibilidad), pero crea problemas para mantener la coherencia
(sincronización de datos).

3.6. Acoplamiento ajustado (tight coupling)

El acoplamiento ajustado (o acoplamiento apretado) es un tipo de
acoplamiento que describe un sistema en el que el hardware y el software
no solo están vinculados entre sí, sino que también dependen entre sí. En un
sistema estrechamente acoplado en el que múltiples sistemas comparten
una carga de trabajo, por lo general, todo el sistema tendría que apagarse
para solucionar un problema de hardware importante, no solo el sistema
único (o subsistema) con el problema.
En el software, el término acoplamiento ajustado se usa para definir el
software que funcionará solo en una parte de un tipo específico de sistema
y el software depende de otro software. Por ejemplo, un sistema operativo
se consideraría estrechamente acoplado, ya que depende de los
controladores de software para instalar y activar correctamente los
dispositivos periféricos del sistema.

9
4. Comunicación con RPC
La llamada a procedimiento remoto o el RCP (de los términos en inglés,
remote procedure call) es un protocolo que permite a un programa ejecutar
en una máquina distinta alguna parte de código, despreocupándose de las
comunicaciones entre ambos equipos. El programador no tiene que estar
pendiente de las comunicaciones debido a que están encapsuladas dentro
de las llamadas o RCP.
En la arquitectura cliente-servidor, el cliente utiliza una RCP para realizar la
solicitud al servidor que ejecute algún procedimiento o función y, a la vez,
es el servidor quien envía de regreso el resultado de dicha operación al
cliente.
Con el RPC, aparece el concepto de stub. Un stub es una función que
proporciona a la comunicación remota una semántica de llamada a
procedimiento y, a la vez, oculta el sistema de mensajes.
El stub del cliente es un representante del procedimiento remoto en el nodo
del cliente que tiene su misma interfaz (nombre, argumentos, semántica),
pero que no realiza la funcionalidad del procedimiento, sino que empaqueta
los argumentos del procedimiento remoto, los adecúa al formato estándar
y construye los mensajes de red. Las funciones que realiza el stub del cliente
son las siguientes:

 empaqueta los parámetros en un mensaje (paramater marshalling);

 envía el mensaje al servidor;
 espera la respuesta al mensaje;
 desempaqueta la respuesta.

El stub del servidor, también conocido como skeletons, es el soporte de

ejecución de un procedimiento o conjunto de procedimientos remotos.
Generalmente, es un proceso del servidor, en lugar de una biblioteca. Las
funciones que realiza el stub del servidor son similares a las del cliente, pero,
además, se encarga de las siguientes:

 Crear hilos: en caso de servidor con múltiples hilos, crea un hilo para
gestionar cada invocación.
 Dispatching: selecciona el procedimiento remoto solicitado (si hay
varios) y lo invoca, actuando como hilo representante del cliente.
El uso de stubs permite a los desarrolladores despreocuparse de detalles
correspondientes a la comunicación, facilitándose, a la vez, el desarrollo de
aplicaciones distribuidas.
Existen dos enfoques básicos para la generación de stubs:

10
  Generación automática por un preprocesador de RPC: como el
rpcgen, de Sun Microsystems.
 Generación “a mano” por el propio programador: es una buena
práctica de programación separar el código independiente de red y el
código dependiente de la red en procedimientos separados. Este
último código está constituido por los stubs (y skeletons).

Figura 2: Funcionamiento de RPC

Fuente: elaboración propia.

Una llamada convencional a un procedimiento (ver Figura 2), en una sola

máquina, funciona de la siguiente manera:
1. el procedimiento del cliente llama al stub del cliente de la manera
usual,
2. el stub del cliente construye el mensaje y hace un señalamiento al
núcleo,
3. el núcleo envía el mensaje al núcleo remoto,
4. el núcleo remoto proporciona el mensaje al stub del servidor,
5. el stub del servidor desempaca los parámetros y llama al servidor,
6. el servidor realiza el trabajo y regresa el resultado al stub,
7. el stub del servidor empaca el resultado en un mensaje y hace un
señalamiento al núcleo,
8. el núcleo remoto envía el mensaje al núcleo del cliente,
9. el núcleo del cliente da al mensaje al stub del cliente,
10. el stub desempaca el resultado y de esta forma regresa al cliente.

11
5. Comunicación en grupo
Se conoce como grupo a un conjunto de procesos que actúan juntos en un
sistema o que actúan en alguna forma previamente determinada por el
usuario. La característica principal de los grupos es que todos los integrantes
del grupo reciben el mismo mensaje enviado, se trata de una comunicación
de uno a muchos, que se distingue de la comunicación punto a punto o
puntual.
Aquí se maneja lo que se conoce como multitransmisión (multicast), donde
se crea una dirección especial de red donde todas las computadoras del
sistema pueden escuchar los mensajes que recibe esa dirección.
Las redes que no soportan la multitransmisión operan con transmisión
simple, donde se envían los mensajes con la dirección de entrega de cada
computadora y, a la vez, cada una debe verificar mediante su propio
software si el paquete va dirigido a ella; en caso negativo, se descarta.
En la unitransmisión (unicast) la comunicación en grupo se realiza desde el
emisor mediante la transmisión de paquetes individuales a cada uno de los
miembros del grupo.
Del mismo modo que los procesos, los grupos deben tener una dirección. Se
le puede dar a cada grupo una dirección única, tal como una dirección de
proceso.
 Si una red soporta multitransmisión, la dirección del grupo se asocia
con una dirección de multitransmisión; de ese modo, cada mensaje
enviado a la dirección del grupo se podrá multitransmitir al grupo.
 Si la red no soporta multitransmisión, se utiliza transmisión simple,
donde se extrae la dirección del grupo y solo se realiza la transmisión
del mensaje a los miembros del grupo; en caso de que no existan
miembros del grupo, se descarta.
 Si la red no soporta multitransmisión ni transmisión simple, se tendrá
que utilizar unitransmisión y enviar a cada máquina el mensaje.

12
6. Primitivas send y receive
Con la comunicación en grupo no resulta aplicable el esquema de RPC
debido a que existe la posibilidad de varias respuestas diferentes. Es por ello
que se utiliza un modelo en un solo sentido, donde se usan llamadas
explicitas para el envío y recepción.
Si se unifican las primitivas puntuales y grupales para Send, uno de los
parámetros indica el destino, ya sea una direccción de un proceso o una
dirección de grupo; y un segundo parámetro apunta al mensaje por enviar.
Si se fusionan las primitivas puntuales y grupales para Receive, la operación
finaliza cuando llega un mensaje puntual o un mensaje de grupo.

7. Atomicidad
Se denomina atomicidad o transmisión atómica a la propiedad que
determina si los mensajes enviados al grupo se entregan correctamente a
todos los miembros o a ninguno de ellos. Esto facilita la programación de los
sistemas distribuidos y es de gran importancia porque garantiza la
consistencia de las bases de datos y de los archivos distribuidos y duplicados.

13
Referencias
Offnfopt. (2 de mayo de 2015). Pila de capas o niveles del modelo OSI (open
system interconnection) [Imagen]. Recuperada de
https://es.wikipedia.org/wiki/Modelo_OSI#/media/File:OSI_Model_v1.svg

14