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 4444 The UDP: User Defined Package: like writing a letter Secuencias lectura/escritura comunicación UDP o TCP Tramas y direcciones IP 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) Programa servidor web Web recursos requerimiento respuesta THE INTERNET requerimiento respuesta Programa cliente web

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

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

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

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

Servicios provistos por múltiples servidores Cliente Servidor1 Servidor2 Servidor1

Proxy servers y caches 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 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

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

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 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 Si un cliente quiere usar los servicios del server 1 debe contactar al host 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 ???....) A SERVER A CLIENT mensaje 4444 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) ?

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 ? 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 ! 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 ? 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 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..... A SERVER A CLIENT ?

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 ?

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 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 proceso El 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 Videoconferencia Temperatura cada segundo Servidor y cliente Web Valores de las acciones cada 5 segundos