Temario

1
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

2
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)

3
Introducción

• Cc50h otoño 2003

4
Por qué sistemas distribuidos

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

5
Ya sabemos cómo se comunican los computadores
pero...
6
... 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
7
Cada capa tiene la ilusión de estar comunicándose
con la correspondiente
A CLIENT
The UDP User Defined Package like writing a
letter
Secuencias lectura/escritura
A SERVER
4444
comunicación UDP o TCP
A CLIENT
Tramas y direcciones IP
A CLIENT
electric pulses
8
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

9
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
10
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
11
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).

12
El paradigma cliente-servirdor (Por ej. la Web)
respuesta
Programa servidor web
THE INTERNET
requerimiento
Web recursos
requerimiento
respuesta
Programa cliente web
13
1- El servidor abre un canal por el cual comienza
a oir peticiones.
SERVIDOR
?
1
INTERNET
Web recursos
CLIENTE
14
2- Un cliente que conoce esto, manda un mensaje y
espera una respuesta
SERVIDOR
2
INTERNET
Web recursos
2
CLIENTE
15
3- El servidor analiza el request y manda una
respuesta de acuerdo al protocolo preestablecido
SERVIDOR
3
THE INTERNET
Web resources
3
Esto pasa a todo nivel !!!
CLIENTE
16
El Modelo Cliente-servidor
Servidor2
invocación
Cliente
Servidor1
resultado
Cliente
Servidor3
17
Servicios provistos por múltiples servidores
Servidor1
Cliente
Servidor1
Cliente
Servidor2
18
Proxy servers y caches
Servidor1
Cliente
Proxy/cache
Cliente
Servidor2
19
Aplicaciones pares
Aplicacón Coordinación
Aplicacón Coordinación
Aplicacón Coordinación
20
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).

21
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)

22
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.

23
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

24
Arquitectura replicada
Datos
Datos
Datos
vista
datos
Comp
25
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)

26
Arquitectura parcialmente replicada
Datos
Datos
Datos
27
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

28
Arquitectura totalmente centralizada
Vista / comandos
Vista / comandos
29
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 216 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 ???)
30
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

31
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)

32
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
33
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
34
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
35
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
36
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
37
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
38
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
39
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
40
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
A CLIENT
bla
bla
3333
4444
41
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
42
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
43
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
44
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.

45
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.

46
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