temario introducción clientes tcp servidores iterativos tcp servidores concurrentes udp...
TRANSCRIPT
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