Programando servidores Posttulo 2004 Programando servidores Qu pasa

Programando servidores Postítulo 2004

Programando servidores • Qué pasa en el servidor cuando el cliente trata de hacer un rendezvous ? • El server empieza a oir requests de clientes en un Server. Socket • Después de que el rendezvous se hizo )

Sockets en el Servidor (1) • El servidor debe empezar por crear un socket servidor y asociarlo a un port desde donde escucuchará peticiones de posibles clientes que quieran conectarse. Server. Socket escuchando; escuchando = new Server. Socket(5555); • Con esto sólo ha creado el socket pero no está escuchando. Para poder empezar a escuchar debe hacer: Socket = escuchando. accept(); • Esta instrucción hace varias cosas: – accept bloquea la ejecución del programa hasta que recibe una petición de un cliente por ese port (recordemos: llamando = new. . ) – cuando llega un requerimiento de conexión, se crea un circuito virtual entre ambos computadores. El cliente recibe un extremo de esa conexión y el servidor la otra. Este otro extremo se asocia a otro socket que el sistema escoge convenientemente.

Sockets en el Servidor (2) • El servidor puede ejecutar los mismos métodos sobre su socket para abrir un flujo de entrada y salida de datos. • Aquí es importante el protocolo de la comunicación que a estas alturas no es más que el lenguaje de comunicación entre servidor y cliente: cuándo leer/escribir, qué datos mandar, cómo reaccionar, etc. . . • Notar que tanto el servidor como el cliente están con un socket de la misma clase después de haber establecido la comunicación), por lo tanto el servidor también puede ejecutar métodos tales como: – Inet. Address get. Inet. Address() – int get. Port() – Inet. Address get. Local. Address() – int get. Local. Port() – void set. So. Timeout(int timeout), int get. So. Timeoute() – void set. So. Linger(Boolean on, int val), int get. So. Linger() (el delay después de un close()) – close()

Servidor de echo El servidor de echo espera hasta que alguien pida un rendezvous. Luego lee línea por línea lo que el cliente envía y responde exactamente lo mismo. La conexión termina cuando el cliente corta la comunicación. 2 3 Servidor de Echo 7 1 Echo. Server Cliente

Servidor de fechas El servidor de fechas espera hasta que alguien solicite un rendez vous. Cuando el cliente lo hace (1), el servidor responde con la fecha actual (2) y luego corta la comunicación (3). 2 Servidor de fechas 3 13 1 Date. Server Cliente

Programemos algo simple • El Talk. Server espera que alguien trate de comunicarse • El Talk. Client pregunta por un nombre de host y trata de coomunicarse • Luego de efectuada la comunicación, todo lo que se escriba en el cliente será transmitido al servidor y mostrado en pantalla Bla bla del teclado Bla bla Talk client Talk Server

Esquema de los programas Open server socket port =4444 While(true) { accept call open reading from socket while (true) { read line from socket if (line. equals(“bye”)) break; write line to screen } //end of the call } Talk. Server s=new Socket(args[0], 4444) open writing to socket while (true) { read line from keyboard write to socket if (line. equals(“bye”)) break; } Talk. Client

Sockets: Transmisión de Archivos (1) • Hagamos ahora un programa que envía un archivo de un programa a otro. • El que recibe el archivo se pone a escuchar para que le manden un archivo (es el servidor !!!) • El emisor del archivo sabe donde está escuchando el receptor para recibir la petición de transmisión de archivos. • El traspaso se hace a nivel de bytes para poder traspasar cualquier tipo de archivo.

Una situación de transmisión de archivos 1) El receptor queda escuchando a ver si alguien quiere mandarle algo 2) El emisor trata de contactar al recibidor Enviar bytes 5) Escribir bytes en archivo 3) Leer bytes desde archivo Repetir 3, 4, 5 hasta que todo el archivo sea transmitido Ver programas Arch. Emisor. java Arch. Receptor. java

Sockets: Transmisión de Archivos (2) • El Servidor queda esperando una petición en un port • Cuando llega una petición lee el nombre del archivo a entregar • Abre el archivo y lo transmite por el socket. • El cliente trata de conectarse con el servidor en el port acordado • una vez que resulta envía el nombre del archivo que quiere recuperar • Lee hasta que encuentra un fin de archivo y lo va guardando en un archivo del mismo nombre que el original.

Un servidor de archivos más inteligente 1) Nombre de archivo desde teclado 2) Solicitar archivo 4) Enviar archivo 5) Escribir archivo 3) Leer archivo Repetir 3, 4, 5 hasta que todo el archivo sea transmitido Ver programas Arch. Server. java Arch. Cliente. java

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

Un ejemplo con 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

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

Servidores Stateless vs. Stateful: el problema de lectura de un archivo remoto. requerimiento abrir archivo XYZ A CLIENT A SERVER ? Respuesta archivo XYZ existe y está listo Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file

Un servidor stateless (sin estado) implica que no se acuerda de las peticiones anteriores requerimiento leer bytes 0 a 49 de XYZ A CLIENT A SERVER ? Respuesta: el contenido en bytes Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file

El cliente debe proporcionar toda la información de nuevo ! reuquerimiento leer bytes 50 a 99 de XYZ A CLIENT A SERVER ? Respuesta: el contenido en 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 requerimiento leer bytes X a X+50 de XYZ A CLIENT A SERVER ? Respuesta: el contenido en bytes Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file

Stateful Server: mantiene alguna información de lo que ha pasado Pointer archi Posición 0 XYZ 0 1 ZXY 50 Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file Req. abrir XYZ A SERVER ? respuesta: file pointer a XYZ A CLIENT

La información que tiene que transmitir el cliente es mucho menos Pointer Archivo Posición 0 XYZ 50 1 ZXY 50 Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file Req. 0, leer 50 A SERVER ? respuesta: el contenido A CLIENT

La información en la tabla debe ser actualizada Pointer Archivo Posición 0 XYZ 100 1 ZXY 50 Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file Req. 0, leer 50 A SERVER ? respuesta: el contenido A CLIENT

Es importante cerrar el archivo Pointer Archivo Posición 0 XYZ 100 1 ZXY 50 Open file XYZ read first 50 bytes while (not end of file XYZ) read next 50 bytes close file Req. 0, leer 50 A SERVER ? respuesta: el contenido A CLIENT

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

Un ejemplo de servidor de archivos con estado • Implementaremos con Archivos de texto (esto puede cambiarse facilmente) • Recibe comandos para abrir archivo para lectura o escritura, cerrar archivo, leer siguiente linea (para archivos abiertos para lectura) y escribir linea (para archivos abiertos para escritura) • El “estado” se guarda en una tabla de hashing y en el objeto java Buffered. Reader o Print. Writer correspondiente al archivo (posición de lectura/escritura)

Un ejemplo de servidor de archivos sin estado • Implementaremos con Archivos de Acceso aleatorio de bytes • Recibe comandos para leer o escribir un cierto número de bytes a partir de una posición específica

Arquitectura de un Servidor de Archivos Aplicación Módulo Cliente Servicio de Directorio Servicio plano de archivo (flat)

Componentes • Flat File Service: Implementa las operaciones directamente sobre los archivos. Trabaja con Unique File Identifieres (UFID). Se genera uno nuevo por cada archivo • Directory Services: Cliente de el FFS, provee un mapeo entre los UFID y los nombre textuales de los archivos y las funciones necesarias para administrar directorios y obtener las UFID. Los directorios se guardan como archivos planos. • Módulo Cliente: Corre en cada computador, integra y extiende las operaciones del FFS y DS en una aplicación interfaz usada por los programadores. Posee información acerca de la localización de archivos en la red. Provee eficiencia a través de un cache

Modelo de Interfaz para FFS • read(File. Id, i, n) : le hasta n bytes de un archivo a partir de la posición i los que retorna en un arreglo • write(File. Id, i, Datos): escribe la secuencia de datos en el archivo a partir de la posición i extendiéndolo en caso • create() : crea un archivo nuevo de largo 0 y devuelve el UFID para él • delete(File. Id) : borra el archivo • get. Attributes(File. Id) : retorna una estructura con los atributos • set. Attributes(File. Id, attr) : pone los atributos según la estructura

Controles de acceso • En un sistema local el chequeo se hace sólo al abrir el archivo y los derechos se conservan • en un sistema distribuido los chequeos se deben hacer a nivel de servidor. Para que el servidor siga siendo stateless se pueden usar 2 estrategias: – El chequeo se hace cuando el nombre es convertido en UFID y el resultado es codificado en forma de capacidad que se retorna al cliente, el cual lo usa para futuros accesos – La identificación del usuario se hace cada vez que se manda un request y el chequeo se hace para cada operación • El segundo es más usado (en NFS y AFS) por su simplicidad, pero ninguno garantiza seguridad en el caso de identidad suplantada

Modelo de interfaz para Directory Service • Lookup(Dir, File) localiza el nombre de texto en el directorio y retorna el UFID • Add. Name(Dir, Name, File) Si Name no estaba en el directorio dado añade el par (Name, File) en el directorio modificando el archivo pertinente • Un. Name(Dir, Name) el par (Name, file) correspondiente es borrado del directorio • get. Names(Dir) retirna la lista de nombres que contiene un directorio

Ejemplo 1 el NFS Aplicación Sistema Virtual Sist Local Client NFS Server NFS Sist Local

Características de NFS • La comunicación es por medio de RPC y es abierta en el servidor, que reside en el kernel • La identificación de archivos es por medio de los llamados file handters consistentes en: • Filesystem identifier • i-node number or file • i-node gerneration number • El “estado” se guarda en el cliente en un v-node • Autentificación del cliente en cada llamada mandando user ID y group ID • Los servicios de flat file y directory están integrados • El servicio de mount provee un link a un sistema remoto

Cache en NFS • Cache en Unix: buffer cache, read ahead, delayed write • Cache en Server: datos de escritura se guardan en memoria cache y son escritas antes del reply al cleinte. En la versión 3 se guarda todo en cache hasta que se recibe la operación commit para ese archivo (buffer lleno o close) • Cache en el servidor: resultados de read, write, getattr, lookup y readdir se almacenan localmente, lo cual puede introducir inconsistencias en versiones en los distintos clientes ya que escrituras de un cliente no se actualizan en seguida en los otros. Los clientes son entonces responsables de mantener actualizados sus caches por medio de timestamps: Tc= tiempo de la última actualización, Tm= tiempo de modificación. A un tiempo T el cache será válido si (T - Tc < t) o (Tmcliente = Tmserver). Normalmente 3 -30 seg para archivos y 30 -60 para directorios

Interfaz de NFS simplificada • read(File. Id, i, n) : le hasta n bytes de un archivo a partir de la posición i los que retorna en un arreglo • write(File. Id, i, Datos): escribe la secuencia de datos en el archivo a partir de la posición i extendiéndolo en caso • create() : crea un archivo nuevo de largo 0 y devuelve el UFID para él • delete(File. Id) : borra el archivo • get. Attributes(File. Id) : retorna una estructura con los atributos • set. Attributes(File. Id, attr) : pone los atributos según la estructura

Ejemplo 2: El AFS • Apunta a lograr mejor performance en situaciones de escalabilidad – Whole-file serving: El contenido de todo los directorios archivos son traspasados al cleinte – Whole-file caching: Los archivos transmitidos son guardados en cache local. Normalmente varios cientos de archivos ! El cache es casi permanente. – Cuando se hace un open del archivo se transmite el archivo entero si no estaba – las operaciones de escritura/lectura se hacen localmente – Con el close, se transmite una copia modificada al servidor – Debe

Esquema del AFS Aplicación Unix Kernel Sist Local Vice Venus Unix Kernel

Consistencia del Cache • Cada vez que se traspasa un archivo del servidor a un cliente se provee de una promesa de callback, que garantiza que cuando otro cliente modifique el archivo este será notificado • El callback puede estar en dos estados: valido o cancelado • Cuando el archivo es traspasado al cliente el callback se pone en válido. Cuando se recibe un callback del servidor (porque el archivo fue modificado) se pone en cancelado • Cada vez que el cliente abre un archivo busca si está en su cache. Si está se revisa el callback. Si está cancelado se trae una copia nueva del archivo, si está válido, se usa el archivo del cache • Si la estación de trabajo se reinicia (por que se apagó o se cayó) pide para cada archivo de su cache el timestamp de la última modificación • si la última modificación es consistente con la copia se pone el callback en válido, si no en cancelado