Comunicación en Sistemas Distribuidos
Tipos de comunicación
Comunicación Persistente:
almacena el mensaje (información)
enviado por el emisor el tiempo que tome entregarlo al receptor.
Comunicación Transitoria:
almacena un mensaje sólo mientras las
aplicaciones del emisor y receptor están en
ejecución.
Comunicación asincrónica:
el emisor continúa inmediatamente después
de que ha pasado su mensaje para la
transmisión.
Comunicación sincrónica: el emisor es bloqueado
hasta que se sabe que su petición es aceptada.
Las características de
la comunicación entre Procesos
El paso de mensajes entre un par de procesos se puede basar
en dos operaciones: envía y recibe, definidas en función del destino
y del mensaje. Para que un proceso se pueda comunicar con otro, el proceso
envía (una secuencia de bytes) a un destino y otro proceso en el destino recibe
el mensaje. Esta actividad implica la comunicación de datos desde el proceso
emisor al proceso receptor y puede implicar además la sincronización de los
procesos.
Comunicación Síncrona
y Asíncrona
A cada destino de mensajes se asocia una cola. Los procesos
emisores producen mensajes que serán añadidos a las colas remotas mientras que
los procesos receptores eliminarán mensajes de las colas locales. La
comunicación entre los procesos emisor y receptor puede ser síncrona o
asíncrona.
En la forma síncrona, los procesos receptor y emisor se sincronizan
con cada mensaje. En este caos, tanto envía como recibe son operaciones
bloqueantes. A cada envía producido el proceso emisor se bloquea hasta que se
produce el correspondiente recibe. Cuando se invoca un recibe, el proceso se
desbloquea hasta que llega un mensaje.
En la forma de comunicación asíncrona, la utilización de la
operación envía es no bloqueante, de modo que el proceso emisor puede continuar
tan pronto como el mensaje haya sido copiado en el buffer local, y la transmisión
del mensaje se lleva a cabo en paralelo con el proceso emisor. La operación
recibe puede tener variantes bloqueantes y no bloqueantes. En la variable no
bloqueante, el proceso receptor sigue con su programa después de invocar la
operación recibe, la cual proporciona un búffer que será llenado en un segundo
plano, pero el proceso debe ser informado por separado de que su búffer ha sido
llenado, ya sea por el método de encuesta o mediante una interrupción.
Destino de los
mensajes
Los mensajes son enviados a direcciones construidas por
pares (dirección internet, puerto local). Un puerto local es el destino de un
mensaje dentro de un computador, especificado como un número entero. Un puerto
tiene exactamente un receptor pero puede tener muchos emisores. Los procesos
pueden utilizar múltiples puertos desde lo que recibir mensajes. Generalmente,
los servidores hacen públicos sus números de puerto para que sean utilizados
por los clientes. Siel cliente utiliza una dirección Internet fija para
referirse a un servicio, entonces ese servicio debe ejecutarse siempre en el
mismo computador para que la dirección se considera válida.
Fiabilidad
Se dice que un servicio de mensajes punto a punto es fiable
si se garantiza que los mensajes se entregan a pesar de poder dejar caer o
perder un número razonable de ellos. Por el contrario, puede decirse que un
servicio de mensajes punto a punto es no fiable si no se garantiza la entrega
de los mensajes ante la pérdida o eliminación incluso de un solo paquete.
Respecto a la integirdad, los mensajes deben llegar sin corromperse ni
duplicarse.
Ordenación
Algunas aplicaciones necesitan que los mensajes sean
entregados en el orden de su emisión, esto es, en el orden en el que fueron
transmitidos por el emisor. La entega de mensajes desordenados, por esas
aplicaciones es considerada como un fallo.
Sockets
La comunicación entre procesos consiste en la transmisión de
un mensaje entre un conector de un proceso y un conector de otro proceso. Para
los procesos receptores de mensajes, su conector debe estar asociado a un
puerto local y a una dirección de internet y a un número de puertos concretos,
sólo se pueden ser recibidos por el proceso cuyo conector tanto para enviar como
para recibir mensajes. Cada computador permite
un gran número de puertos posibles, que pueden ser usados por los
procesos locales para recibir mensaje. Cada proceso puede utilizar cerios
puertos para recibir mensajes, pero un proceso no puede compartir puertos con
otros procesos del mismo computador. Los procesos que utilizan multidifusión IP son una excepción ya si comparten puertos.
No obstante, cualquier cantidad de procesos puede enviar mensajes a un mismo
puerto. Cada conector se asocia con un protocolo concreto, que puede ser UDP o
TCP.
Utilización de UDP
Para algunas aplicaciones, resulta aceptable utilizar un
servicio que sea susceptible de sufrir fallos de omisión ocasionales. Por
ejemplo, el servicio de nombres de dominio en internet (Domain Name Service ,
DNS) está implementado sobre UDP. Los datagramas UDP son en algunas ocasiones, una
elección atractiva porque no padecen las sobrecargas asociadas a la entrega de
mensajes garantizada. Existen tres fuentes principales para la sobrecarga:
1.
La necesidad de almacenar información de estado
en el origen y en el destino.
2.
La transmisión de mensajes extra.
3.
La latencia para el emisor.
Utilización de TCP
Muchos de los servicios utilizados se ejecutan sobre
conexiones TCP, con números de puertos reservados. Entre ellos se encuentran
los siguientes:
HTTP: El protocolo
de transferencia de hipertexto se utiliza en comunicación entre un navegador y
un servidor web.
FTO: El protocolo
de transferencia de archivos permite leer los directorios de un computador
remoto y transferir archivos entre los computadores de una conexión.
Telnet: La
herramienta Telnet nos proporciona acceso a una terminal en un computador
remoto.
SMTP: El
protocolo simple de transferencia de correo se utiliza para mandar correos
electrónicos entre computadores.
Comunicación Cliente-Servidor
Esta forma de comunicación está orientada a soportar los
roles y el intercambio de mensajes de las interacciones típicas
cliente-servidor. En el caso normal, la comunicación petición respuesta es
síncrona, ya que el proceso cliente se bloquea hasta que llega la respuesta del
servidor es, en efecto, un acuse de recibo para el cliente. La comunicación
cliente-servidor asíncrona es una alternativa que puede ser útil en situaciones
donde los clientes pueden recuperar las respuestas más tarde.
El protocolo
Petición-respuesta
El siguiente protocolo está basado en un trío de primitivas
de comunicación hazOperación, damePetición, enviaRespuesta.
La primitiva hazOperación
se utiliza en el cliente para invocar las operaciones remotas. Sus argumentos
especifican el objeto remoto y el método a invocar junto con información
adicional (argumentos) requerida por el método. Su resultado es una respuesta
RMI.
La primitiva damePeticion
se usa en el servidor para hacerse con las peticiones de servicio. Cuando el
servidor ha invocado el método sobre el objeto especificado, utiliza el método
enviaRespuesta para mandar el mensaje de respuesta al cliente. Cuando el cliente
recibe el mensaje de respuesta, desbloquea la operación hazOperacion y continúa la ejecución el programa cliente.
La primitiva hazOperación
en un cliente genera un idPetición,
para cada mensaje de petición y el servidor lo copia al correspondiente mensaje
de respuesta. Esto hace posible que hazOperacion
pueda comprobar que un mensaje de respuesta es el resultado de la petición
actual, no de una invocación que se ha retrasado.
Comunicación en grupo
Una operación de multidifusión envía un único mensaje desde
un proceso a cada uno de los miembros de un grupo de procesos, normalmente de
modo que la pertenencia al grupo resulte transparente para el emisor. Existe un
abanico de posibilidades respecto al comportamiento deseado de la
multidifusión. La más simple no proporciona garantía alguna sobre la entrega
del mensaje y el mantenimiento del orden de la emisión de los mismos.
Los mensajes de multidifusión proporcionan una
infraestructura para construir sistemas distribuidos con las siguientes características:
- Tolerancia a fallos basada en servicios replicados: un servicio replicado consta de un grupo de servidores. Las solicitudes de los clientes se dirigen a todos los miembros del grupo y cada uno de ellos realiza la misma operación. Incluso cuando varios de los miembros fallen, los clientes todavía serán servidos.
- Búsqueda de los servidores de descubrimiento en redes espontáneas: Los servidores y los clientes pueden utilizar la multidifusión mensajes para localizar los servicios disponibles, y registrar sus interfaces o para buscar las interfaces de otros servicios en el sistema distribuido.
- Mejores prestaciones basada en datos replicados: Los datos se replican para incrementar las prestaciones de un servicio; en algunos casos se colocan réplicas de los datos en los computadores de los usuarios. Cada vez que se producen cambios en los datos, el nuevo valor se comunica a los procesos que gestionan las réplicas de los datos mediante multidifusión.
- Propagación de las notificaciones de eventos: la multidifusión a un grupo puede utilizarse para notificar a los procesos que algo ha sucedido.
La diferencia más importante entre un sistema distribuido y
un sistema de un único procesador es la comunicación entre procesos. En un
sistema de un solo procesador la comunicación supone implícitamente la
existencia de la memoria compartida: En un sistema distribuido no existe la
memoria compartida y por ello toda la naturaleza de la comunicación entre
procesos debe replantearse. Los procesos, para comunicarse, deben apegarse a
reglas conocidas como protocolos .Los mensajes se intercambian de diversas
formas, existiendo muchas opciones de diseño al respecto; una importante opción
es la “llamada a un procedimiento remoto”.
Trabajos citados
Coulouris, G. (2001). Sistemas Distribuidos: Conceptos
y Diseño. Madrid: Addison Wesley.
Informática, D. d.
(2010). Universidad de la Patagonia San Juan Bosco. Recuperado el 17 de
08 de 2013, de Universidad de la Patagonia San juan Bosco:
http://www.ing.unp.edu.ar/asignaturas/sistemasdistribuidos/2010/SD-UNPSJB-2010-mod2.pdf
No hay comentarios.:
Publicar un comentario