CC52N Computacion para el apoyo al trabajo grupal Programación de aplicaciones distribuidas en Internet INTERNETWORKING

Objetivos 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

¿ Es necesario una introduccion a la Internet ? Direcciones IP Algotimo de ruteo Tipos de redes físicas DNS Yes No Abort

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 deben ser publicados (conocidos).

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

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.

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 NOTAS

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 NOTAS

Un 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 NOTAS

Stateless 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

A 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

The 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

This may cause a lot of network traffic, especially if there are many clients Request read bytes X to X+50 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

Stateful Server: it mantains some information abut what clients did Pointer File Position Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file 0 XYZ 0 1 FILE ZXY 50 Request open file XYZ A CLIENT A SERVER ? Answer: file pointer to file XYZ

The information the client has to pass to the server is much smaller Pointer File Position Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file 0 XYZ 50 1 FILE ZXY 50 Request 0, read 50 A CLIENT A SERVER ? Answer: the content

The information at the server should be updated with every request Pointer File Position Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file 0 XYZ 100 1 FILE ZXY 50 Request 0, read 50 A CLIENT A SERVER ? Answer: the content

It is important to close the file !!! Pointer File Position Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file 0 XYZ 100 1 FILE ZXY 50 Request 0, read 50 A CLIENT A SERVER ? Answer: the content

Un ejemplo del servidor de Archivos Posibilidades de errores 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. NOTAS

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). NOTAS

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

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

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

¿ Es necesario una introducción a JAVA ? Clases Herencia Tipos, operaciones básicas control de flujo Yes No Abort