El Cliente-Servidor es un sistema distribuido entre mltiples Procesadores donde hay clientes que solicitan servicios y servidores que los

proporcionan. La Tecnologa Cliente/Servidor, es un modelo que implica productos y servicios enmarcados en el uso de la Tecnologa de punta, y que permite la distribucin de la informacin en forma gil y eficaz a las diversas reas de una organizacin (empresa o institucin pblica o privada), as como tambin fuera de ella. Este es uno de los sistemas fundamentales sobre los que se sustenta la computacin moderna y que pese al mucho tiempo que tiene en uso, va creciendo da a da. Cliente Es el que pide servicio de Internet o Intranet. Una aplicacin consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas. Los usuarios invocan la parte cliente de la aplicacin, que construye una solicitud para ese servicio y se la enva al servidor de la aplicacin que usa TCP/IP como transporte. Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes Puntos Administrar la interfaz de usuario. Interactuar con el usuario. Procesar la lgica de la aplicacin y hacer validaciones locales. Generar requerimientos de bases de datos. Recibir resultados del servidor. Formatear resultados.

Servidor Es una aplicacin que ofrece un servicio a usuarios de Internet, el servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar mltiples peticiones (mltiples clientes) al mismo tiempo. Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes Puntos Aceptar los requerimientos de bases de datos que hacen los clientes. Procesar requerimientos de bases de datos. Formatear datos para trasmitirlos a los clientes. Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de datos

El objetivo de esta prctica es el diseo e implementacin de un servidor de nombres jerrquico, usando para ello una arquitectura cliente/servidor. La comunicacin entre el servidor de nombres (SN) y los clientes de ejemplo se realizar mediante sockets. Pasos a seguir Se debern seguir los siguientes pasos en la implementacin: 1. Desarrollo de una librera de funciones que facilite el uso de sockets. Esta librera ser de gran utilidad para todos los pasos posteriores, as como la implementacin de las siguientes prcticas. 2. Desarrollo de un servidor de echo (SE) para validar la librera anterior. El SE deber escuchar sobre un puerto pasado como parmetro, y cuando establezca comunicacin con un cliente, deber responder con los mismos datos que reciba. El servidor se puede probar con el programa telnet. 3. Desarrollo de un cliente de echo (CE) sencillo, que funcione con el servidor anterior. 4. Ampliacin del SE para que soporte varios clientes simultneamente. Esto se har mediante el empleo de hilos (procesos ligeros), por lo que es altamente recomendable desarrollar una librera de funciones para el manejo de POSIX pthreads. 5. Desarrollo del servidor de nombres, usando como base el SE y el CE anteriores. El SN realizar las siguientes funciones: a. Leer su configuracin de un fichero de texto. El formato del fichero de configuracin se explica ms adelante. b. Escuchar peticiones en un puerto pasado como argumento. Cada vez que reciba una peticin, buscar en su tabla de direcciones y, en caso de necesidad, preguntar a sus superiores/inferiores (cuando un SN pregunta a otro, acta como cliente). Una vez obtenidas la direccin IP y el puerto solicitados, responder al cliente estos mismos datos. 6. Adaptar el CE para que solicite la direccin del SE al SN antes de conectarse (la direccin se introducir manualmente en el fichero de configuracin del SN). Los clientes recibirn, como parmetro de entrada, el nombre de un fichero de configuracin en el que se enumeran el/los SN a los que conectarse para buscar direcciones. 7. Opcionales a. Implementar ms servidores con sus respectivos clientes, por ejemplo un servidor de tiempo, un servidor de fecha, etctera. Los clientes debern hacer uso del SN para encontrar a sus respectivos servidores. b. Implementar un mecanismo de cach de forma que el SN vaya ampliando sus propias tablas a medida que va solicitando direcciones a los servidores que se encuentran por encima y por debajo de l en la jerarqua. c. Posibilidad de utilizar indistintamente protocolos conexionistas y no conexionistas. Mediante UDP, un cliente puede solicitar de forma rpida un servicio de nombres al SN, y mediante TCP una respuesta truncada en el caso de que sta sea necesaria, es decir, cuando debe resolverse la direccin IP de la mquina solicitada con ms de un SN de la jerarqua. Estos servicios del SN se considerarn por separado.

Documentacin adicional
Para realizar esta prctica, se tendrn en cuenta los siguientes aspectos: Funcionamiento de los sockets:

El protocolo C/S. Control de flujo. Manejo de errores. Funcionamiento de un servidor multi-proceso. Tratamiento de hilos posix. Bloqueo. Formato del archivo de configuracin del SN

El fichero de configuracin consistir en una lista de parejas {<nombre_servidor>, <direccin IP y puerto>}, donde un nombre de servidor ser siempre una serie de palabras separadas por puntos (ej.: time.upiicsa.ipn). Los campos sern los siguientes: El nivel (dominio) del SN, que ser un fragmento de nombre de servidor (ej.: upiicsa.ipn) Una lista de servidores de nombres que se encuentran por debajo de l, en formato {<extensin_servidor>, <direccin IP y puerto>} La direccin y el puerto del SN que se encuentra por encima de l en la jerarqua, en el caso de que exista. Como ejemplo tenemos, en el caso de upiicsa.ipn, ser la direccin del SN responsable de ipn.

Ejemplo de fichero de configuracin (direcciones ficticias), # # Archivo de configuracin del SN # # nivel propio upiicsa.ipn # servidores registrados (e.g) date.upiicsa.ipn 150.251.99.12:110 finger.upiicsa.ipn 150.251.99.13:7

# direcciones de servidores inferiores (e.g.) ii.upiicsa.ipn 150.251.77.121:8600 it.upiicsa.ipn 150.251.78.207:8800

# direccion de servidor de nivel superior, si lo hay (e.g) es 150.173.44.56:8700

Funcionamiento del SN jerrquico

Cuando el SN recibe una solicitud, realiza las siguientes operaciones: Si es el responsable del nivel

Si tiene el nombre solicitado en su tabla, devuelve la direccin y el puerto correspondientes. Si no est en su tabla, devuelve error Si no lo es,

Si el final de la direccin coincide con su nivel, realiza la solicitud al SN inferior correspondiente. Si no lo encuentra, sealiza error. Si el final de la direccin no coincide con su nivel, realiza la solicitud al SN de nivel superior. Si no conoce a ningn SN de nivel superior, devuelve error. Arrancando varios SN con distintos ficheros de configuracin se pueden generar los distintos "niveles" de la jerarqua de servidores de nombres.

La estructura de SN de la figura anterior es coherente con el fichero de configuracin para upiicsa.ipn mostrado ms arriba. Para buscar la direccin y el puerto del servidor time.ii.upiicsa.ipn, preguntando al servidor upiicsa.ipn, los pasos seran los siguientes: 1. El SN upiicsa.ipn recibe una peticin de resolucin de time.ii.upiicsa.ipn. Como no es el responsable del nivel, pasa la peticin al SN de nivel inferior ii.upiicsa.ipn. 2. El SN ii.upiicsa.ipn recibe la peticin y mira en su tabla. Responde con la direccin y el puerto pedidos al SN upiicsa.ipn. 3. El SN upiicsa.ipn responde la peticin original con los datos devueltos por ii.upiicsa.ipn.

Si, por el contrario, la direccin buscada fuera time.escom.es, el proceso sera el siguiente: 1. El SN upiicsa.ipn recibe una peticin de resolucin de time.ucm.es. Como no es el responsable del nivel, pasa la peticin al SN de nivel superior es. 2. El SN es pasa la peticin a ucm.es. 3. El SN ucm.es busca en su tabla, y devuelve a es la direccin pedida. 4. El SN es devuelve el resultado a upiicsa.ipn. 5. Finalmente, el SN upiicsa.ipn responde a la peticin original con los datos solicitados.

Este algoritmo puede funcionar para cualquier nmero de niveles, de forma que la implementacin no debe limitarse a un nmero fijo de niveles (ejemplo: podra darse el caso de que un SN de nivel 10 necesite realizar una solicitud que se resolver en el nivel 2).