Temario• Introducción• Clientes TCP • Servidores Iterativos TCP • Servidores Concurrentes • UDP• Multicasting • Sincronización de procesos distr.• Objetos remotos• Middleware para sist distr. • Programacion en la Web

Evaluación• 2 controles 1 exámen

– control 1 después de Servidores concurrentes – control 2 después de Middleware para ...– Examen entra todo

• 4 Tareas obligatorias + 1 recuperativa

• Un trabajo de investigación (grupo de 2-3 personas)

Introducción

Cc50h otoño 2003

Por qué sistemas distribuidos

- Compartir recursos- Comunicar personas- Performance, escalabilidad- sistemas tolerantes a fallas

Ya sabemos cómo se comunican los computadores pero...

... Cómo se comunican los programas ?

PROG1 PROG2

Necesitan establecer un protocolo !

- Quién manda los datos primero- Qué tipo de datos- Cómo reaccionar a los datos

Cada capa tiene la ilusión de estar comunicándose con la correspondiente

A SERVER

A CLIENT

A CLIENT

A CLIENT

4444

The UDP: User Defined Package: like writing a letterSecuencias lectura/escritura

comunicación UDP o TCP

Tramas y direcciones IP

electricpulses

Decisiones al Desarrollar un Sistema Distribuido

• Qué servicio de la capa de transporte vamos a usar (TCP, UDP, o un middleware)

• Arquitectura del Software : replicada, centralizada• Arquitectura de las comunicaciones : centralizada,

en red• Diseño de los servidores : concurrentes, iterativos,

con/sin estado• Etc…

Internet : Dos maneras básicas para transmitir mensajes (desde el punto de

vista del programador)

The UDP: User Defined Package: like writing a letter

TCP or UDP

Hoy día hay una gran oferta de middleware que hace la programación

de sistemas distribuidos más fácil

Bibliotecas y servicios para el desarrollo (middleware)

RPC, CORBA, RMI

Arquitecturas Cliente-Servidor

• ¿ Qué son las arquitecturas cliente/servidor ? – El modelo cliente/servidor (oidor/llamador)

• Porque TCP/IP no provee ningun mecanismo que automáticamente cree un programa que empeice a ejecutarse cuando llega un mensaje, un programa debe esperar a aceptar una comunicación ANTES que el requerimiento llegue.

• ¿ Existe otra forma de comunicarse ?– Multicasting (el servidor no tiene idea de los clientes)

• ¿ Qué son los ports de protocolo de una máquina ?– Es una dirección dentro de la máquina en la cual hay un programa

servidor escuchando si hay algun cliente que quiere solicitar algún servicio que él presta. En máquinas UNIX hay “ports bien conocidos” para ciertos servicios. Para acceder a los servicios se debe seguir un cierto protocolo. Tanto el port como el protocolo deben ser publicados (conocidos).

El paradigma cliente-servirdor (Por ej. la Web)

Programa servidor web

Webrecursos

requerimiento

respuesta

THE INTERNET

requerimientorespuesta

Programa cliente web

1- El servidor abre un canal por el cual comienza a “oir” peticiones.

SERVIDOR

Webrecursos

INTERNET

CLIENTE

1 ?

2- Un cliente que conoce esto, manda un mensaje y espera una respuesta

SERVIDOR

Webrecursos

INTERNET

CLIENTE

2

2

3- El servidor analiza el request y manda una respuesta de acuerdo al

protocolo preestablecido

SERVIDOR

Webresources

THE INTERNET

CLIENTE

3

3

Esto pasa a todo nivel !!!

El Modelo Cliente-servidor

Cliente

Cliente

Servidor1

Servidor2

Servidor3

invocación

resultado

Servicios provistos por múltiples servidores

Cliente

Cliente

Servidor1

Servidor2

Servidor1

Proxy servers y caches

Cliente

Cliente

Proxy/cache

Servidor2

Servidor1

Aplicaciones “pares”

Aplicacón+

Coordinación

Aplicacón+

Coordinación

Aplicacón+

Coordinación

Arquitecturas de comunicaciones para Aplicaciones Distribuidas

• Servidores como Clientes– Los programas no siempre se comportan definitivamente como

servidores puros o como clientes puros. Ej: un servidor de archivos que necesita un timestamp para registrar el último cambio.

– Cuando todas las aplicaciones deben comportarse simultáneamente como servidores y clientes: ¿ cómo organizar las comunicaciones ?

• Cada aplicación abre un canal con otra aplicación (configuración red)

• Hay un servidor de comunicaciones y todoas las aplicaciones se comunican con él (configuración estrella).

Arquitectura de comunicación en red

• Cada par de aplicaciones que necesitan comunicarse abren un canal exclusivo

• Se abren a lo más n*(n-1)/2 canales para n aplicaciones

• Ventajas: – un canal exclusivo, no hay cuellos de botella

• Desventajas: – todas las aplicaciones deben saber cómo comunicarse con las demás. – La dinámica se vuelve más complicada (entrada/salida de aplicaciones)

Arquitectura de comunicación en estrella

• Las aplicaciones envían sus requerimientos de comunicación a un servidor y éste se encarga de mandarlas a su punto de destino final.

• Se abren a lo más n canales para n aplicaciones

• Ventajas: – Es más fácil manejar los parámetros de la comunicación

• Desventajas: – se puede saturar el servidor o las líneas.

Arquitecturas Replicadas

• Cada computador tiene una copia de la aplicación y los datos

• Modificaciones locales se “distribuyen” a todos los participantes

• sincronización normalmente por eventos, no por estados

• Qué pasa con los que llegan más tarde ?

• La aplicación es normalmente la misma para todos

• la arquitectura de las comunicaciones puede ser centralizada o en red

Arquitectura replicada

Datos

DatosDatos

vista

datos

Comp

Arquitecturas Semi Replicadas

• Los datos se mantienen centralizados en un servidor

• Cada cliente mantiene su propia “vista” actualizada de los datos

• modelo único, varias vistas y controlador replicados

• Uso de interfaces distintas frecuente

• Sincronizacion por estado y eventos igualmente posible

• Arquitectura de las comunicaciones normalmente centralizada (servidor de comunicaciones donde esta el modelo)

Arquitectura parcialmente replicada

Datos

Datos

Datos

Arquitecturas Centralizadas

• Los datos y la vista se mantienen centralizados en un servidor

• Cada cliente aporta un servidor gráfico para desplegar la vista

• Todos comparten los mismos datos y las vistas

• Sincronización por nedio de estado (de la vista)

• Arquitectura de las comunicaciones simpre centralizada

• Necesidad de implementar filtros

• Provoca gran tráfico de datos (ya que se refresca la vista)

• De uso general

Arquitectura totalmente centralizada

Vista / comandos

Vista / comandos

Implementación de Comunicaciones en red TCP/IP

• A “bajo” nivel (¿futuro “assembler de las comunicaciones”?)

- Basado en la abstracción “sockets” y “ports”- Originalmente desarrollado para BSD UNIX pero presentes ahora en casi todos los sistemas (UNIX, LINUX, Macintosh OS, Windows NT)- El destino de un mensaje se establece por dirección de máquina y número de port (esto es verdad también en comunicaciones a más “alto nivel”) cada máquina tiene 2**16 ports- El origen del mensaje es a través de un socket en el cual “pocas” veces importa el port al cual está amarrado- Ports se asocian a servicios (también de comunicación)- Otros sistemas usan IP address y número de proceso (ventajas, desventajas ???)

Las 3 formas básicas• UDP lo más parecido a lo que realmente pasa en la internet El cliente manda un paquete a través de un socket (amarrado a cualquier) dirigido a un ip-address y a un port. El servidor espera recibir paquetes en un port acordado• TCP Simula un flujo de datosEl cliente debe establecer primero una comunicación con el servidor, luego escribe. El servidor debe estar “esperando” la comunicación en un port acordado para luego leer y/o escribir en el flujo de datos abierto • Multicast especial para comunicación en grupos cuando el grupo no está definido desde un principio (sponaneous networking) ya que es igual a UDP pero puede ser recibido por cualquier host que se interese (usa direcciones ip “generales”). Comunicaciones sin servidor central

Protocolos para la comunicación• Cada servicio utiliza un protocolo de

comunicación– Web: HTTP (port 80)– Mail: SMTP– Archivos remotos: FTP– Archivos en red: NFS

• Servidores con/sin Conexión– Las modalidades connectionless style y connection-

oriented style dependen del tipo de protocolo que usemos para conectarnos con una máquina. En el mundo TCP/IP tenemos protocolos TCP (con conexion) y UDP (sin conexión)

El canal usado por las aplicaciones para enviar mensajes (TCP o UDP) se

llama SOCKET

SERVER 1

Cuando un servidor quiere empezar a recibir requerimientos de abre un socket y lo amarra a un port, el cual se identifica con un número

SERVER 2

SERVER 3

www.thisserver.jp

4444

3333

5555

Si un cliente quiere usar los servicios del server 1 debe contactar al host www.thisserver.jp por el port 4444

UDP: Comunicación con datagramasDATAGRAMA: “an independent, self-contained message sent over the internet whose arrival, arrival time and content are not guaranteed” (como el correo en Chile ???....)

A SERVER A CLIENT

4444

www.waseda1.jp

www.waseda1.jp

mensaje

4444

Una vez que el servidor está corriendo, el cliente debe armar undatagrama con la dirección del servidor, número de port y losdatos (mensaje)

www.waseda2.jp

?

Luego debe abrir un socket y enviar el datagrama a la internet. El “routing algorithm” encontrará el camino al computador de destino

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

?

Enviando datagramas con el protocolo UDP

Antes de salir del computador el sistema le coloca al datagrama los datos del remitente

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

!

Enviando datagramas con el protocolo UDP

Si el cleinte espera respuesta del servidor (dependiendo del protocolo de la aplicación) puede empezar a esperar datagramas por el mismo port

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

?

Enviando datagramas con el protocolo UDP

El servidor extrae los datos del remitente, los cuales usa para armar el datagrama de respuesta

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

answer

?

Enviando datagramas con el protocolo UDP

Enviando datagramas con el protocolo UDP

Finalmente el servidor envía la respuesta al cliente (que desde el punto de vista de la programación está convertido en un servidor). El mensaje puede llegar o no, o incluso llegar duplicado. Si se quiere tener seguridad se debe implementala “a mano” o usar. . . . .

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

?

TCP: comunicación con flujo de datos

Con TCP se construye primero un canal (virtual) entre las dos aplicaciones por medio de un rendezvous que el cliente intenta a un servidor que está escuchando.

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

?

TCP: comunicación con flujo de datos

Luego que el cliente contacta al servidor se establece un canal “seguro” de flujo de datos. Por este, el cliente y el servidor pueden enviarse datos. Deben ponerse de acuerdo quién manda que y cómo se reacciona con anterioridad.

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

bla bla bla bla

TCP: cómo se logra la seguridad ?La internet misma funciona con el paradigma de los datagramas “best efort”. Por lo tanto se requiere por parte del enviador recibir una señal de acuso de recibo

Sending bla bla bla

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Ack 2nd bla

Sending 3rd bla

Ack 3rd bla

¿ Si se pierde el mensaje ?El enviador espera un tiempo “razonable” para recibir la confirmación. En caso que esto no ocurra lo manda de nuevo

Sending bla bla bla

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Sending 2nd bla again

Ack 2nd bla

No hay confirmación !!!

LOST !!!

Eficiencia en el procesoEl enviador va a manejar un paquete de mensajes no confirmados

Sending 1st bla

Ack 1st bla

Sending 2nd bla

Ack 2nd bla

Sending 3rd bla

Ack 3rd bla

Protocolos TCP y UDP (I)

• Importancia para el programador: – Al elegir un protocolo con el cual conectarse con otra máquina

determina el nivel de confiabilidad de la transmisión de datos, lo cual repercute en la forma de programar las aplicaciones.

• TCP provee alta confiabilidad: los datos mandados serán recibidos si una conexión entre los 2 computadores se pudo establecer. Hay un protocolo subyacente que se preocupa de retransmitir, ordenar....

• Con UDP el programador debe proveer el protocolo para el caso que se pierdan datos o lleguen en otro orden.

– La forma de programar el envío recibo de datos con ditintos protocolos es también distinta:

• En TCP la forma de transmitir datos es normalmente como un flujo de datos por la conexión establecida.

• Con UDP se deben armar paquetes de datos que son pasados a la internet para ser transmitidos “con el mejor esfuerzo”.

Protocolos TCP y UDP (II)• ¿ Cuándo usar uno u otro ?

– TCP impone una carga bastante mayor a la red que UDP, por lo cual se debe evitar si es “razonablemente posible”

• ¿ Cuándo es “razonablemente posible” ?– Podemos esperar pérdidas cuando los datos tienen que viajar a traves de varias

redes por la internet.– Dentro de una LAN las comunicaciones UDP son relativamente confiables– Algunas veces la información que no llegó a tiempo no tiene sentido

retransmitirla porque ya está obsoleta (¿cuándo?).

• En general se recomienda, especialmente a principiantes, usar sólo TCP en sus aplicaciones. El estilo de programación es más secillo. Los programadores sólo usan UDP si el protocolo de la aplicación misma maneja la confiabilidad, si la aplicación requere usar broadcast o multicast de hardware o la aplicación no puede tolerar el overhead de un circuito virtual.

Marcar con + las aplicaciones donde se deba usar TCP y con - las que se puede

usar UDP

E-Mail Videoconferencia

Temperatura cada segundo

Servidor y cliente Web

Valores de las acciones cada 5 segundos