Title: CC52N Computacion para el apoyo al trabajo grupal
1CC52N Computacion para el apoyo al trabajo grupal
Programación de aplicaciones distribuidas en
Internet INTERNETWORKING
2Objetivos del Capítulo
- 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 ejemplos de programas distribuidos
3 Es necesario una introduccion a la Internet ?
- Direcciones IP
- Algotimo de ruteo
- Tipos de redes físicas
- DNS
Yes
No
Abort
41- 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 deben ser
publicados (conocidos).
5Protocolos 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
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)
6Protocolos 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.
7Protocolos 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.
8Servidores 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
9Un 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
10Un ejemplo del servidor de Archivos (II)
- Situación guardardando información del estado
- 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
11Stateless vs. Stateful servers the problem of
reading a remote file by steps. File reading
requests arrive with dealy
Request open file XYZ
A CLIENT
A SERVER
?
Answer file XYZ exists and ready
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
12A stateless server means it does not remember
previous requests
Request read bytes 0 to 49 from file XYZ
A CLIENT
A SERVER
?
Answer the content of the bytes
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
13The client must provide all the information again
!
Request read bytes 50 to 99 from file XYZ
A CLIENT
A SERVER
?
Answer the content of the bytes
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
14This may cause a lot of network traffic,
especially if there are many clients
Request read bytes X to X50 from file XYZ
A CLIENT
A SERVER
?
Answer the content of the bytes
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
15Stateful Server it mantains some information
abut what clients did
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 0
1 FILE ZXY 50
Request open file XYZ
A CLIENT
A SERVER
?
Answer file pointer to file XYZ
16The information the client has to pass to the
server is much smaller
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 50
1 FILE ZXY 50
Request 0, read 50
A CLIENT
A SERVER
?
Answer the content
17The information at the server should be updated
with every request
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 100
1 FILE ZXY 50
Request 0, read 50
A CLIENT
A SERVER
?
Answer the content
18It is important to close the file !!!
Open file XYZ read first 50 bytes while (not end
of file XYZ) read next 50 bytes close file
Pointer File Position
0 XYZ 100
1 FILE ZXY 50
Request 0, read 50
A CLIENT
A SERVER
?
Answer the content
19Un ejemplo del servidor de Archivos
- 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.
20Arquitecturas 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).
21Arquitecturas 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)
22Arquitecturas 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.
232- InterNetworking con Java
- Por qué JAVA ?
- En este curso Los programas son más simples gt
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) gt 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.
24 Es necesario una introducción a JAVA ?
- Clases
- Herencia
- Tipos, operaciones básicas
- control de flujo
Yes
No
Abort