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 4 Tareas obligatorias + 1 recuperativa 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 ? 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 CLIENT A SERVER The UDP: User Defined Package: like writing a letter Secuencias lectura/escritura 4444 comunicación UDP o TCP A CLIENT Tramas y direcciones IP A CLIENT electric pulses

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) respuesta Programa servidor web THE INTERNET requerimiento Web recursos requerimiento respuesta Programa cliente web

1- El servidor abre un canal por el cual comienza a “oir” peticiones. ? 1 INTERNET Web recursos CLIENTE

2- Un cliente que conoce esto, manda un mensaje y espera una respuesta SERVIDOR 2 INTERNET Web recursos 2 CLIENTE

3- El servidor analiza el request y manda una respuesta de acuerdo al protocolo preestablecido THE INTERNET Web resources 3 Esto pasa a todo nivel !!! CLIENTE

El Modelo Cliente-servidor invocación Servidor2 Cliente resultado Servidor1 Cliente Servidor3

Servicios provistos por múltiples servidores Cliente Servidor1 Cliente Servidor2

Proxy servers y caches Servidor1 Cliente Proxy/cache Cliente Servidor2

Aplicaciones “pares” 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 Datos Datos 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 datos El 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 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 www.thisserver.jp 4444 SERVER 1 3333 SERVER 2 SERVER 3 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 datagramas DATAGRAMA: “an independent, self-contained message sent over the internet whose arrival, arrival time and content are not guaranteed” (como el correo en Chile ???....) Una vez que el servidor está corriendo, el cliente debe armar un datagrama con la dirección del servidor, número de port y los datos (mensaje) www.waseda1.jp www.waseda2.jp A SERVER A CLIENT ? 4444 www.waseda1.jp 4444 mensaje

Enviando datagramas con el protocolo UDP Luego debe abrir un socket y enviar el datagrama a la internet. El “routing algorithm” encontrará el camino al computador de destino www.waseda2.jp www.waseda1.jp A SERVER A CLIENT ? 3333 4444

Enviando datagramas con el protocolo UDP Antes de salir del computador el sistema le coloca al datagrama los datos del remitente www.waseda2.jp www.waseda1.jp A SERVER A CLIENT ! 3333 4444

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 www.waseda2.jp www.waseda1.jp A SERVER ? A CLIENT 3333 4444

Enviando datagramas con el protocolo UDP El servidor extrae los datos del remitente, los cuales usa para armar el datagrama de respuesta www.waseda2.jp www.waseda1.jp A SERVER ? A CLIENT 3333 4444 answer

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. . . . . www.waseda2.jp www.waseda1.jp A SERVER ? A CLIENT 3333 4444

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. www.waseda2.jp www.waseda1.jp A SERVER A CLIENT ? 3333 4444

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. www.waseda2.jp www.waseda1.jp bla bla A SERVER bla A CLIENT bla 3333 4444

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 1st bla Sending bla bla 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 1st bla Sending bla bla bla Ack 1st bla Sending 2nd bla LOST !!! Sending 2nd bla again No hay confirmación !!! Ack 2nd bla

Eficiencia en el proceso El enviador va a manejar un paquete de mensajes no confirmados Sending 1st bla Sending 2nd bla Sending 3rd bla Ack 1st bla Ack 2nd 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 Videoconferencia E-Mail Servidor y cliente Web Valores de las acciones cada 5 segundos Temperatura cada segundo