Download postituloBaloian - DCC

Document related concepts
no text concepts found
Transcript
Módulo ECI - 11: Fundamentos de Redes de Computadores
Desarrollo de Aplicaciones
en Redes
de Computadores
Nelson Baloian, DCC, U. de Chile
1
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Objetivos del Curso
Conocer los paradigmas actuales de la
programación distribuida
 Conocer y usar algunos mecanismos para
programar aplicaciones comunicantes
Evaluar los distintos mecanismos para su
uso en algún contexto dado
Desarrollar peueños ejemplos de
programas distribuidos
2
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Contenidos del Curso (I)
 Introducción:
 Arquitecturas cliente/servidor
 Protocolos de comunicación (conexión y estado)
 Arquitecturas de aplicaciones distribuidas
 Internetworking en JAVA
 ¿Por qué JAVA ?
 (Introducción a JAVA: estructura, IO, paralelismo, OO)
 La clase InetAddress
 Los Sockets




Definición
Sockets TCP
Sockets UDP (el multicast UDP)
clientes, servidores, concurrencia, mantencion de estado
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
3
Módulo ECI - 11: Fundamentos de Redes de Computadores
Contenidos del Curso (II)
 RMI
 concetos básicos
 Serialización de objetos
 XDR
 Otros Sistemas
 Sockets en C
 Sockets en Perl
 CORBA
 El Network File System (NFS) de UNIX




Servidores sin estado
El sistema de archivos UNIX
Modos de Archivos NFS
Operaciones
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
4
Módulo ECI - 11: Fundamentos de Redes de Computadores
Contenidos del Curso (III)
 Programando la seguridad
 Dónde es necesario aplicarla ?
 Generando claves y flujos de datos encriptados
 El SSL
 Ejemplos tradicionales:
 Cleinte Ping
 Servidor talk (o chat)
 Servidor WEB
 Consideraciones de Diseño en Sistemas Multiusuarios




Awarness
Data locking
Versioning
Distributed Software Development
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
5
Módulo ECI - 11: Fundamentos de Redes de Computadores
1- Introducción
 ¿ 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
6
deben ser
publicados
(conocidos).
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Protocolos para la comunicación
 Parametrización de los clientes
 Se busca generalidad de los programas. Ej: telnet sirve para
accesar también otros servicios (tratar de ejecutar telnet host 7,
telnet host 13 y telnet host 80)
Cuando diseñe programas de aplicación cliente, incluya parámetros
que permitan al usuario especificar totalmente la máquina y el port
al que quiera comunicarse con el protocolo que implementa el
programa.
 Servidores con/sin Conexión
 Las modalidades connectionless style y connectio-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)
7
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
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”.
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
8
Módulo ECI - 11: Fundamentos de Redes de Computadores
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.
9
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Servidores Con o sin Estado
 ¿ Qué es el Estado ?
 El “estado” es la información que los servidores mantienen acerca
de la interacción que se lleva a cabo con los clientes.
 ¿ Para qué ?
 Generalmente se hace más eficiente el comporatamiento de los
servidores con información. Información muy breve mantenida en
el servidor puede hacer más chicos los mensajes o permite
producir respuestas más rápido.
 ¿ Y entonces por qué se evita a veces ?
 Es fuente de errores: mensajes del cliente pueden perderse,
duplicarse llegar en desorden. El cliente puede caerse y rebootear,
con lo cual la información que tiene el servidor de él es errónea y
también sus respuestas
10
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ejemplo del servidor de Archivos
El servidor espera que un cliente se conecte por la red. El
cleinte puede mandar 2 tipos de requerimientos: leer o
escribir datos en un archivo. El servidor realiza la
operación y retorna el resultado al cliente.
 Situación sin guardar información acerca del estado:
 Para leer, el cliente debe siempre especificar: nombre de archivo,
posición en el archivo desde dónde debe extraer los datos y el
número de bytes a leer.
 Para escribir debe especificar el nombre completo del archivo, el
lugar donde quiere escribir y los datos que quiere escribir
11
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ejemplo del servidor de Archivos (II)
 Situación guardardando información del estado:
Handle
1
2
3
4
Filename
miArchivo.txt
unDocumento.doc
unJuego.exe
Hola.java
Posición
0
456
38
128
 Cuando el cliente abre un archivo se crea un entrada en la tabla. A la entrada
se le asigna un handle para identificar el archivo y se le asigna la posición
actual (inicialmente 0). El cliente recibe el handler como respuesta.
 Cuando el cliente quiere extrer datos adicionales le envia el handle y la
cantidad de bytes. Esto es usado por el servidor para saber gracias a la tabla
de dónde exactamente debe extraer los datos (debe actualizar la posición para
que para la próxima vez se pueda hacer lo mismo).
 Cuando el cliente termina la lectura/escritura envía un mensaje para sea
eliminada la entrada de la tabla
12
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ejemplo del servidor de Archivos (III)
 Posibilidades de errores
Handle
1
2
3
4




Filename
miArchivo.txt
unDocumento.doc
unJuego.exe
Hola.java
Posición
0
456
38
128
La red manda dos veces el datagrama con requerimiento de lectura
Si el computador del cleinte se cae y rebootea el programa.
Si el computador se cae antes de poder “des-registrarse”
Si otro cliente se conecta en el mismo port que el que se cayó sin
avisar
En una internet real, donde las máquinas pueden caerse y rebootear y
los mensajespueden perderse, llegar atrasados, duplicados o en
orden incorrecto un servidor con manteción de estado puede resultar
difícil de programar para hacerlo tolerante a los errores.
13
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Arquitecturas 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).
14
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Arquitecturas para Aplicaciones
Distribuidas
 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)
15
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Arquitecturas para Aplicaciones
Distribuidas
 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*(n-1)/2 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.
16
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
2- InterNetworking con Java
 ¿ Por qué JAVA ?
 En este curso: Los programas son más simples => se peude usar más
tiempo en explicar la lógica de los programas que para explicar las
instrucciones del lenguaje.
 En general: Java nace cuando la internet ya está madura (1993-4) => nace
“sabiendo” que existe TCP/IP y que la programación distribuida es
importante, lo que se nota en el diseño.
 Además de las típicas funcionalidades básicas de comunicación
(comunicación por canales TCP y UDP) incorpora otras de alto nivel de
abstracción: RMI, Applets, JDBL, URL
 ¿ Siempre es mejor JAVA ?
 No, Java es multiplataforma por lo tanto sólo puede hacer cosas que sean
comúnes a todas las plataformas.
 Con la estandarización de TCP/IP como red virtual para todos los equipos
esto es cada vez menos importante. Aún así hay cosas: Nombres y ports
sólo se pueden asociar en C ya que es exclusivo de UNIX.
17
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl