41
COMUNICACIÓN ENTRE PROCESOS. Ing. Luis Jara Obregón, Msc.

Comunicación entre procesos Sistemas distribuidos

Embed Size (px)

Citation preview

Page 1: Comunicación entre procesos Sistemas distribuidos

COMUNICACIÓN ENTRE PROCESOS.

Ing. Luis Jara Obregón, Msc.

Page 2: Comunicación entre procesos Sistemas distribuidos

1. INTRODUCCIÓN.

2. LA INTERFAZ DE PROGRAMACIÓN DE APLICACIONES PARA LOS PROTOCOLOSDE INTERNET.

3. REPRESENTACIÓN EXTERNA DE DATOS EMPAQUETADO.

4. COMUNICACIÓN CLIENTE-SERVIDOR

5. COMUNICACIÓN EN GRUPO.

6. CASO DE ESTUDIO: COMUNICACIÓN ENTRE PROCESOS EN UNIX.

7. RESUMEN.

Page 3: Comunicación entre procesos Sistemas distribuidos
Page 4: Comunicación entre procesos Sistemas distribuidos

COMUNICACIÓN ENTRE PROCESOS.

• La interfaz de programación de aplicaciones (API) de java para la comunicación entre

procesos en internet proporciona comunicación tanto por datagramas como streams.

Los streams son los objetos que se encargan de conectar

el programa con las distintas fuentes o destinos de los

datos que se procesan (teclado, monitor, disco duro,

sockets...).

Un datagrama es un paquete de datos que constituye el

mínimo bloque de información en una red de

conmutación por datagramas.

Page 5: Comunicación entre procesos Sistemas distribuidos

TCP VS. UDP

} UDP

Este protocolo es orientado a

conexión.

Este protocolo es de conexiones

inferiores.

La conexión TCP es flujo de bytes La conexión UDP es un flujo de

mensajes

Proporciona control de errores y

control de flujo

No se proporciona el control de

errores ni control de flujo.

TCP admite la transmisión full duplex UDP no admite transmisión full duplez

Es un servicio confiable de

transmisión de datos

Este es un servicio poco fiable de

transmisión de datos.

El paquete TCP se llama como

segmento.

El paquete UDP se llama como

datagramas de usuario.

Page 6: Comunicación entre procesos Sistemas distribuidos

TCP (Transmission Control Protocol

• EL CLIENTE INDICA QUÉ SERVICIO QUIERE, LO HACE CON LA DIRECCIÓN IP DESTINO

Y PUERTO.

• PUERTOS: ENTRE 0 Y 65.535

• DEL 0 AL 1023 ESTAN ESTANDARIZADOS, LOS PUERTO UDP SON LOS MISMOS, PERO

NO SE MEZCLAN LOS DATOS.

• EL CLIENTE SOLICITA EN SU SISTEMA UN NÚMERO DE PUERTO PARA USO PROPIO.

Page 7: Comunicación entre procesos Sistemas distribuidos

TCP (Transmission Control Protocol

Cliente

Dirección IP

192.168.1.15

¡¡¡OPERADORA¡¡¡

DAME UN PUERTO

PARA REALIZAR

UNA CONEXIÓN

EXTERNA,….¿EL

33580 ESTA LIBRE

Servidor

Dirección

192.168.1.1

PUERTO

8033580

¡¡¡¡SERVIDOR¡¡¡ ME

QUIERO CONECTAR A TU

PUERTO 80 DESDE MI

PUERTO 33580

OK PIDE

LO QUE

QUIERAS

Conexión establecida

ID único

192.168.1.1:80/192.168.1.15:33580

Page 8: Comunicación entre procesos Sistemas distribuidos

MECANISMOS DE FIABLILIDAD DEL TCPPara evitar pérdidas y duplicados y asegurar el orden.

• Numeración y confirmación.

• Todos los bytes tienen su número de secuencia.

• En la cabecera del segmento va el 1er n° de secuencia.

• Se usa una “Confirmación positiva con retransmisión” (El receptor debe mandar

un ACK para confirmar la recepción. Si no lo hace en un plazo, se retransmite.

• Si un ACK llega tarde al emisor, el receptor se puede encontrar con segmentos

duplicados.

Page 9: Comunicación entre procesos Sistemas distribuidos
Page 10: Comunicación entre procesos Sistemas distribuidos

MECANISMO DE FIABILIDAD DE TCP (2)

• CAMPOS DE CABECERA DE TCP PARA LOS PUERTOS, NÚMEROS DE SECUENCIA Y

LOS ACK.

• …… LA COMUNICACIÓN FLUYE CON NORMALIDAD

• LO ULTIMO QUE HA OCURRIDO CORRECTAMENTE:

• A------B, segmento con los bytes del 20 al 50 y….

• A ----------B, segmento con los bytes del 80 al 100…

• Vemos como funciona la cabecera de TCP:

PUERTO DE ORIGEN (16) PUERTO DE DESTINO (16)

NÚMERO DE SECUENCIA (32)

NÚMERO DE CONFORMACIÓN (32)

Page 11: Comunicación entre procesos Sistemas distribuidos

MECANISMO DE FIABILIDAD DE TCP (2)A

PUERTO

3358

B

PUERTO

80

51…..70 11.- A--B, bytes del 51 al 70 ACK del 80 a 100

ORIGEN 3358 80 DESTINO

N° Sec 51

N° Confirm 101

1Del primer byte ---

enviado

Del Sgte. byte a ---

recibir

101….120

2.- A---B, bytes del 101 al 120 y ACK (51 A 70)

ORIGEN 80 3358 DESTINO

N° Sec 101

N° Confirm 71

3.- A--B, No hay datos nuevos. ACK (101-120)

ORIGEN 3358 80 DESTINO

N° Sec 71

N° Confirm 121

ORIGEN 80 3358 DESTINO

N° Sec 121

N° Confirm 71

4.- A---B, bytes del 121 al 150. Se espera el byte 71

4

2

3

NO

DATA

121….1505

71…90

5.- A-B, bytes del 71 al 90. ACK (121-150

Page 12: Comunicación entre procesos Sistemas distribuidos

Características de la Comunicación entre procesos.

EL PASO DE MENSAJES ENTRE UN PAR DE PROCESOS SE PUEDE BASAR EN DOS OPERACIONES; ENVIA Y RECIBE

ENVIARECIBE

Se define en función del destino y del

mensaje

Para que se pueda comunicar un proceso con otro, se debe enviar un mensaje ( Secuencia de bytes) a un destino y

otro proceso en el destino recibe el mensaje.

Esto actividad requiere comunicación des datos desde el proceso emisor al proceso receptor y puede implicar

también sincronización de los dos procesos.

Page 13: Comunicación entre procesos Sistemas distribuidos

COMUNICACIÓN SINCRONA Y ASINCRONA

Mensaje

LOS PROCESOS EMISORES PRODUCEN MENSAJES QUE SERÁN AÑADIDOS A LAS COLAS REMOTAS,

MIENTRAS QUE LOS PROCESOS ELIMINÁN MENSAJES DE LAS COLAS LOCALES.

Page 14: Comunicación entre procesos Sistemas distribuidos

LA COMUNICACIÓN ENTRE

LOS PROCESOS EMISOR Y

RECEPTOR

SÍNCRONA: Los procesos emisor y

receptor se sincronizan con cada

mensaje. Tanto envía como recibe son

operaciones bloqueantes.

A cada envié producido el proceso

emisor se bloquea hasta que se produce

el correspondiente recibe.

ASÍNCRONA: La utilización de la

operación envía en no bloqueante, de

modo que el proceso emisor puede

continuar tan pronto como el mensaje

haya sido copiado en el búfer local, la

transmisión del mensaje se realiza en

paralelo con el proceso emisor.

Page 15: Comunicación entre procesos Sistemas distribuidos
Page 16: Comunicación entre procesos Sistemas distribuidos

DESTINOS DE LOS MENSAJES.

• En los protocolos de internet, los mensajes son enviados a direcciones construidas por pares

(dirección internet, puerto local).

UN

RECEPTOR

Los procesos pueden utilizar múltiples puertos desde los que recibir mensajes. Cualquier proceso que conozca el

número de puerto apropiado puede enviarle mensajes.

Page 17: Comunicación entre procesos Sistemas distribuidos

Si el cliente utiliza un dirección de internet fija para referirse a un servicio debe ejecutarse

siempre en el mismo computador para que esa dirección se considere valida. esto se evita

usando una de las siguientes aproximaciones que proporcionan transparencia de ubicación.

Los programas se refieren a los servicios por su nombre y utilizan un servidor de nombres o enlazador

para trasladar esos nombres a ubicaciones del servidor en tiempos de ejecución.

El sistema operativo, ej; Mach, proporciona identificadores para los destinos de los mensajes

independientes de la localización, haciéndoles corresponder con direcciones de más bajo nivel para

utilizarlas para entregar los mensajes en los puertos, permitiendo la migración como la reubicación de

los servicios.

Page 18: Comunicación entre procesos Sistemas distribuidos

SOCKETS

• Definición: Un socket es un punto final de enlace de comunicación de dos vías entre

dos programas que se ejecutan a través de la red.

• El cliente y el servidor deben ponerse de acuerdo sobre el protocolo que utilizaran.

Ambas formas de comunicación (UDP y TCP) utilizan la abstracción de sockets, que proporciona los puntos

extremos de la comunicación entre procesos, se origina en UNIX pero ahora están presentes en la mayoría de

sistemas operativos.

Page 19: Comunicación entre procesos Sistemas distribuidos

PRIMITIVAS DE SOCKETS

Por lo general, los servidores ejecutan primero cuatro primitivas, normalmente en el

orden dado. Cuando se llama a la primitiva socket, el que llama crea un nuevo punto

final de comunicación para un protocolo de transporte especifico. De manera interna,

crea un punto final de comunicación significa que el sistema operativo local reserva

recursos para alojar los mensajes enviados y recibidos por el protocolo especificado.

Page 20: Comunicación entre procesos Sistemas distribuidos
Page 21: Comunicación entre procesos Sistemas distribuidos
Page 22: Comunicación entre procesos Sistemas distribuidos

PROCESO

CLIENTE.

CLIENTE

192.168.1.2

8080

PROCESO

SERVIDOR

192.168.1.3

8080

Estoy escuchando a

que un cliente realice

una petición

Yo conozco la

dirección IP de

ese servidor y su

puerto, voy a

realizar una

petición

SE ESTABLECE UN SOCKET DE

COMUNICACIÒN 8081

Page 23: Comunicación entre procesos Sistemas distribuidos

COMUNICACIÓN DE DATAGRAMAS UDP

• Un datagrama enviado por UDP se transmite desde un proceso emisor a un proceso receptor

sin acuse de recibo ni reintentos. Si algo falla, el mensaje no puede llegar a su destino, Se

transmite un datagrama, entre procesos, cuando uno lo envía y otro lo recibe.

• Cualquier proceso que necesite enviar o recibir mensajes debe crear, primero un conector

asociado a un dirección IP y aun puerto local. Un servidor enlazará su conector a un puerto

de servidor (conocido por los clientes). Un cliente ligara su conector a cualquier puerto local

libre. El método recibe devolverá, además del mensaje, la dirección de internet y el puerto del

emisor, permitiendo al receptor enviar la correspondiente respuesta.

Velocidad a

costa de

fiabilidad.No ordena

mensajes.

No controla el

flujo.

Page 24: Comunicación entre procesos Sistemas distribuidos

ASPECTOS REFERENTES A LA COMUNICACIÓN DEDATAGRAMAS.

• Tamaño de mensaje: El receptor necesita especificar una cadena de byte de un tamañoconcreto sobre el cual se almacenará el mensaje recibido, si es demasiado grande serátrucado a su llegada, a pesar de que la capa subyacente permite paquetes de hasta 2^16bytes, incluida la cabecera, en la mayoría de entornos se restringe a 8 kilobytes.

• Bloqueo: La comunicación UDP utiliza operaciones de envió, ENVIA no bloqueantesrecepciones, RECIBE bloqueantes. La operación envía devuelve el control cuando ha dirigidoel mensaje a las capas inferiores UDP e IP, que son las responsables de su entrega.

• El método RECIBE produce un bloqueo hasta que se reciba un datagrama, a menos que sehaya establecido un tiempo limite (timeout) asociado al conector, si el proceso que invoca elmétodo RECIBE tiene que realizar otras tareas mientras espera el mensaje, deberá realizarlasen un hilo separado.

• Tiempo limite de espera: El método RECIBE con bloqueo indefinido es adecuado que estánesperando recibir peticiones desde sus clientes. Pero en algunos programas, no resultaapropiado que un proceso que ha invocado una operación deba esperar indefinidamente.

Page 25: Comunicación entre procesos Sistemas distribuidos

• Recibe de cualquiera: El método RECIBE no especifica el origen de los mensajes. En sulugar al invocar RECIBE aceptamos mensajes dirigidos a su conector desde cualquier origen.El método RECIBE devuelve la dirección de Internet y el puerto del emisor, permitiendo alreceptor comprobar de donde viene el mensaje.

MODELO DE FALLOS

Presenta las siguientes

debilidades.

FALLA DE OMISIÓN:

Los mensajes pueden desecharse

ocasionalmente, ya sea por un error

detectado por la suma de comprobación

porque no queda espacio en el búfer ya

sea en el origen o en el destino.

ORDENACIÓN:

Algunas veces, los mensajes se

entregan en desorden a su origen de

emisión

Page 26: Comunicación entre procesos Sistemas distribuidos
Page 27: Comunicación entre procesos Sistemas distribuidos

APLICACIÓN DEL UDP

En algunas aplicaciones resulta aceptable un modelo que sea susceptible a

fallos de omisión ocasionales. Ej: el servidor de nombres de dominio.

UDP suele ser una elección atractiva porque no padecen de sobrecargas

asociadas a la entrega de mensajes garantiza.

Existen tres fuentes principales para esta sobrecarga:

La necesidad de almacenar información de estado en el origen y en el

destino.

La transmisión de mensajes extra.

La latencia del emisor.

Page 28: Comunicación entre procesos Sistemas distribuidos

UDP

Page 29: Comunicación entre procesos Sistemas distribuidos

COMUNICACIÓN DE STREAMS TCP

• La API para el protocolo TCP, proporciona la abstracción de un flujo de

bytes(STREAMS) en el que puede escribirse y desde el que pueden leerse

datos. La abstracción de streams oculta las siguientes características de la

red:

• TAMAÑO DE MENSAJES: la aplicación permite elegir la cantidad de datos que requiere escribir o leer

el streams.

• MENSAJES PERDIDOS: El protocolo TCP utiliza un esquema de acuse de recibo de los mensajes. El

extremo emisor almacena un registro de cada paquete IP enviado y el extremo receptor acusa el

recibo de todos los paquetes IP que llegan.

• CONTROL DE FLUJO: el protocolo TCP intenta ajustar las velocidades de los procesos que leen y

escriben en un streams. Si escritor es demasiado rápido para el lector este se bloquea.

• DUPLICACIÓN Y ORDENACIÓN DE LOS MENSAJES: a cada paquete IP se le asocia un

identificador, que hace posible que el receptor pueda detectar y rechazar mensajes duplicados.

Page 30: Comunicación entre procesos Sistemas distribuidos

• DESTINOS DE LOS MENSAJES: un par de procesos en comunicación establecen una conexión antes

que puedan comunicarse mediante un stream. Una vez que se ha establecido la comunicación, los

procesos simplemente leen o escriben en el stream sin tener que preocuparse de las direcciones de

internet ni de los números de puerto.

• El API para comunicación por streams supone que en el momento de establecer una conexión, uno de

ellos juega el papel de cliente y el otro juega el papel de servidor, aunque después se comuniquen de

igual a igual. El rol del cliente implica la creación de un conector, de tipo stream, sobre cualquier puerto

y la posterior petición de conexión con el servidor en su puerto de servicio.

• El par de conectores, el del cliente y el del servidor, se conectan por un par de streams, uno en cada

dirección, Así cada conector tiene su propio streams de entrada y de salida.

• Cuando una aplicación cierra un conector indica que no va a escribir nada más en su stream de salida.

Page 31: Comunicación entre procesos Sistemas distribuidos
Page 32: Comunicación entre procesos Sistemas distribuidos

ASPECTOS IMPORTANTES RELACIONADOS CON LACOMUNICACIÓN DE STREAMS:

• Concordancia de Ítems de Datos: Los dos procesos que se comunican necesitan estar de

acuerdo en el tipo de datos transmitidos por el stream.

• Bloqueo: Los datos escritos en un streams se almacenan en un búfer en el conector destino.

Cuando un proceso intenta leer datos de un canal de entrada, o bien extraerá los datos de la

cola o bien se bloqueará hasta que existan datos disponibles.

• Hilos: Cuando un servidor acepta conexión, generalmente crea un hilo con el que

comunicarse con el nuevo cliente. La ventaja de utilizar un hilo separado para cada cliente es

que el servidor puede bloquearse a la espera de entradas sin afectar a los otros clientes.

Page 33: Comunicación entre procesos Sistemas distribuidos

MODELO DE FALLO.Para satisfacer la propiedad de integridad de una comunicación fiable, los streams TCP utilizan

una suma de comprobación para detectar y rechazar los paquetes corruptos, y utilizan un

numero de secuencia para detectar y eliminar los paquetes duplicados.

Para la propiedad de validez, los streams TCP utilizan timeouts y retransmisión de los

paquetes perdidos.

Pero si la pérdida de paquetes sobrepasa un cierto limite, o la red que conecta a un par de

procesos en comunicación esta severamente congestionada, el software TCP responsable de

enviar los mensajes no recibirá acuses de recibo de los paquetes enviados y después de un

tiempo declarará rota la conexión.

Cuando una

conexión esta

rota, se notificara

al proceso que la

utiliza siempre

que intente leer o

escribir

Los procesos que

utilizan la conexión

no distinguen entre

fallo de red y fallo del

proceso.

Page 34: Comunicación entre procesos Sistemas distribuidos

UTILIZACIÓN DE TCP

Muchos de los servicios utilizados se ejecutan sobre conexiones TCP, con números de puerto

de puertos reservados. Entre ellos se encuentran los siguientes:

HTTP: El protocolo de transferencia de hipertexto se utilizan en comunicación entre un

navegador y un servicio web.

FTP: 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 proporciona acceso a un terminal de un computador remoto.

SMTP: El protocolo simple de transferencia de correo se utiliza para mandar correos

electrónicos entre computadoras.

Page 35: Comunicación entre procesos Sistemas distribuidos

API JAVA PARA LOS STREAMS TCP

• La interfaz Java para los streams TCP esta constituida por las clases ServerSocket y

Socket.

• ServerSocket: Esta clase esta diseñada para ser utilizada por un servidor para crear un

conector en el puerto de servidor que escucha las peticiones de conexión de los clientes,

su método “accept” toma una petición “connect” de la cola, o si la cola esta vacia, se

bloquea hasta que llega una petición. El resultado de ejecutar “accept” es una instancia de

Socket, un conector queda acceso a streams para comunicarse con el cliente.

Page 36: Comunicación entre procesos Sistemas distribuidos

CLASE SOCKET• Esta clase es utilizada por el par de procesos de una conexión. El cliente utiliza un constructor

para crear un conector, especificando el nombre DNS de host y el puerto del servidor. Este

constructor no solo crea el conector asociado con el puerto local, sino que también se conecta

con el computador remoto especificando el puerto indicado. Puede lanzar una excepción

“UnknownHostException” si el nombre del host no es el correcto, o una exception

“IOException” si se da un error de entrada y salida.

• La clase Socket proporciona los métodos “getInputStream” y “getOutputStream” para acceder

a los dos streams asociados a un conector. El tipo de datos devueltos por esos métodos son

“InputStream” y OutputStream”

Page 37: Comunicación entre procesos Sistemas distribuidos

REPRESENTACIÓN EXTERNA DE DATOS Y EMPAQUETADO.

La información almacenada dentro de los programas en ejecución se representa mediante estructuras dedatos (ej: conjuntos de objetos interrelacionados”) mientras que la información transportada en losmensajes consiste en secuencias de bytes. Independiente de la forma de comunicación utilizada, lasestructuras de datos deben ser aplanadas (convertidas en una secuencia de bytes) antes de sutransmisión y reconstruidas en el destino.

Los tipos de datos primitivos transmitidos en los mensajes pueden tener valores de muchos tipos distintosy no todos los computadores almacenan valores primitivos. También es diferentes en diferentesarquitecturas la representación de los números en coma flotante.

Page 38: Comunicación entre procesos Sistemas distribuidos

Otro problema es el conjunto de códigos utilizados para representar caracteres, ej: UNIX utiliza

la codificación ASCII con un byte por carácter, mientras que el estándar UNICODE permite

representar la mayoría de lenguajes y utiliza dos bytes por carácter.

Page 39: Comunicación entre procesos Sistemas distribuidos

Existen dos variantes en la ordenación de enteros: la llamada big-endian, en la que el byte más

significativo va primero, y en la llamada little-endian en la que va el ultimo.

Para hacer posible que dos computadores puedan intercambiar datos se puede utilizar uno de

los dos métodos siguientes:

• Los valores se convierten a un formato externo acordado antes de la transmisión y se

revierten al formato local en la recepción; si los dos computadores son del mismo tipo se

puede omitir la transformación al formato externo.

• Los valores se transmiten según el formato del emisor.

aS

S

Z K

Y Y

Page 40: Comunicación entre procesos Sistemas distribuidos

REPRESENTACIÓN EXTERNA DE DATOS.Para soportar RMI o RPC, cualquier tipo de dato que pueda ser pasado como un argumento o

devuelto como resultado debe ser capaz de ser aplanado y cada uno de estos tipos de datos

primitivos representados en una representación de datos acordada. Al estándar acordado para

la representación de estructuras de datos y valores primitivos se le denomina representación

externa de datos.

El empaquetado: consiste en tomar una colección de ítems de datos y ensamblarlos de un modo

adecuado para la transmisión en un mensaje.

El desempaquetado: es el proceso de desensamblado en el destino para producir una colección

equivalente de datos. Por lo tanto empaquetar consiste en traducir las estructuras de datos y los

valores primitivos en una representación externa de datos.

Page 41: Comunicación entre procesos Sistemas distribuidos

SE TRATARÁN LAS DOS ALTERNATIVAS PARA LAREPRESENTACIÓN EXTERNADA DE DATOS Y ELEMPAQUETADO:

La representación común de datos de CORBA, que incumbe a un

representación externa para los datos estructurados y primitivos que puedan

ser pasada como argumento y resultado de la invocación remota de métodos

CORBA. Puede ser utilizada por una gran variedad de lenguajes de

programación.

La serialización de objetos en Java, que está relacionada con el aplanado y la

representación externa de datos de cualquier objeto simple o un árbol de

objetos que tienen que ser transmitidos en un mensaje o almacenados en

disco. Es de uso exclusivo de Java.

En ambos casos, el empaquetado y el desempaquetado son llevados a cabo por

una capa de middleware sin ninguna partición del programador de la aplicación.