May 24, 2022 Trabajo Práctico Especial 2022/1 Revisión 0 Resumen Este documento describe el Trabajo Especial de la materia Protocolos de Comunicación para la cursada del primer cuatrimestre del año 2022. En su ejecución los alumnos DEBEN demostrar habilidad para la programación de aplicaciones cliente/servidor con sockets, la comprensión de estándares de la industria, y la capacidad de diseñar protocolos de aplicación. Terminología Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este documento serán interpretadas como se describe en el RFC 2119 [RFC2119]. Tabla de Contenidos 1. Requerimientos Funcionales . . . . . . . . . . . . . . . . . 1 2. Requerimientos No Funcionales . . . . . . . . . . . . . . . . 2 3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Normative References . . . . . . . . . . . . . . . . . . 6 4.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Requerimientos Funcionales El objetivo del trabajo es implementar un servidor proxy para el protocolo SOCKSv5[RFC1928]. El servidor DEBE [X] 1. atender a múltiples clientes en forma concurrente y simultánea (al menos 500). [X] 2. soportar autenticación usuario / contraseña [RFC1929]. [-] 3. soportar de mínima conexiones salientes a a servicios TCP a direcciones IPv4, IPV6, o utilizando FQDN que resuelvan cualquiera de estos tipos de direcciones. [] 4. ser robusto en cuanto a las opciones de conexión (si se utiliza un FQDN que resuelve a múltiples direcciones IP y una no está disponible debe intentar con otros). [] 5. reportar los fallos a los clientes usando toda la potencia del protocolo. [] 6. implementar mecanismos que permitan recolectar métricas que ayuden a monitorear la operación del sistema. A. cantidad de conexiones históricas B. cantidad de conexiones concurrentes C. cantidad de bytes transferidos D. cualquier otra métrica que considere oportuno para el entendimiento del funcionamiento dinámico del sistema Las métricas PUEDEN ser volátiles (si se reinicia el servidor las estadísticas pueden perderse). [] 7. implementar mecanismos que permitan manejar usuarios cambiar la configuración del servidor en tiempo de ejecución sin reiniciar el servidor. Las diferentes implementaciones PUEDEN decidir disponibilizar otros cambios de ejecución en tiempo de ejecución de otras configuraciones (memoria utilizada en I/O, timeouts, etc). [] 8. implementar un registro de acceso que permitan a un administrador entender los accesos de cada uno de los usuarios. Pensar en el caso de que llega una queja externa y el administrador debe saber quien fue el que se conectó a cierto sitio web y cuando. [] 9. monitorear el tráfico y generar un registro de credenciales de acceso (usuarios y passwords) de forma similar a ettercap por lo menos para protocolo POP3. 2. Requerimientos No Funcionales Adicionalmente, la implementación DEBE [X] 1. Estar escritos en el lenguaje de programación C, específicamente con la variante C11 (ISO/IEC 9899:2011). [X] 2. Utilizar sockets en modo no bloqueante multiplexada. 3. Tener en cuenta todos los aspectos que hagan a la buena performance, escalabilidad y disponibilidad del servidor. Se espera que se maneje de forma eficiente los flujos de información (por ejemplo no cargar en memoria mensajes muy grandes, ser eficaz y eficiente en el intérprete de mensajes). El informe DEBE contener información sobre las pruebas de stress. Algunas preguntas interesantes a responder son: * ¿Cual es la máxima cantidad de conexiones simultáneas que soporta? * ¿Cómo se degrada el throughput? [X] 4. Seguir los lineamientos de IEEE Std 1003.1-2008, 2016 Edition / Base definitions / 12. Utility Conventions [1] a menos que se especifique lo contrario: Esto se refiere a cómo manejar argumentos de línea de comandos, parámetros, etc 5. Deberá documentar detalladamente el protocolo de monitoreo y configuración e implementar una aplicación cliente. [X] 6. Tanto la aplicación servidor, como la aplicación cliente de configuración/monitoreo DEBERÁN manejar los argumentos de línea de comandos de cierta forma uniforme (por ejemplo -c podría especificar el puerto utilizado para el protocolo de configuración/monitoreo). Los detalles de qué parámetros se deben manejar será publicado en otro documento. [X] 7. Si bien las programas son pequeños podrá utilizar librerías o archivos (fragmento de código) desarrollados por terceros siempre que se cumplan los siguientes requisitos: A. La librería o fragmento NO DEBE resolver las cuestiones de fondo del Trabajo Práctico. B. La librería o fragmento DEBE tener una licencia aprobada por la Open Source Initiative [2]. C. El uso de la librería o fragmento DEBE ser aprobada por la Cátedra. Para lograr la aprobación un alumno del grupo DEBE publicar una secuencia en el foro de discusión del trabajo práctico. La secuencia DEBE describir todos aquellos datos que permitan identificar a la librería (por ejemplo la versión); su licencia de esta forma justificando porqué es válido su uso; y el propósito de su inclusión. En caso de que sea un fragmento de código debe adjuntarse. Está permitido utilizar código publicado por los docentes durante la cursada actual, siempre que se atribuya correctamente. [] 8. A veces existirán ambigüedades en las especificaciones o múltiples formas en como se puede resolver o implementar un problema particular. Por ser una materia de ingeniería se espera que los alumnos tomen decisiones de diseño razonables en estos casos. Los alumnos pueden basar sus decisiones en lo que conoce de ante mano de la tarea y en los objetivos enumerados en este documento o demás enunciados. Los docentes pueden darle consejos sobre las ventajas y desventajas de cada decisiones, pero los alumnos son los que en última instancia las toman. 3. Evaluación Cada grupo DEBE entregar todo el material necesario para poder reproducir el Trabajo Práctico. Como mínimo DEBE contener: a. Un informe en formato PDF [RFC3778] o text/plain (con codificación UTF-8) que contenga las siguientes secciones (respetando el orden): 1. Índice 2. Descripción detallada de los protocolos y aplicaciones desarrolladas. 3. Problemas encontrados durante el diseño y la implementación. 4. Limitaciones de la aplicación. 5. Posibles extensiones. 6. Conclusiones. 7. Ejemplos de prueba. 8. Guía de instalación detallada y precisa. No es necesario desarrollar un programa instalador. 9. Instrucciones para la configuración. 10. Ejemplos de configuración y monitoreo. 11. Documento de diseño del proyecto (que ayuden a entender la arquitectura de la aplicación). b. Códigos fuente y archivos de construcción c. Un archivo README en la raíz que describa al menos: A. la ubicación de todos los materiales previamente enumerados B. el procedimiento necesario para generar una versión ejecutable de las aplicaciones C. la ubicación de los diferentes artefactos generados D. cómo se debe ejecutar las diferentes artefactos generados (y sus opciones) La entrega se realizará por Campus ITBA en la asignación creada para ello con una fecha de entrega. Se DEBE entregar un tarball que sea el producto de clonar el repositorio GIT (por lo tanto el repositorio GIT DEBE contener todos los materiales de entrega), y su historia. Una vez realizada la entrega los grupos DEBERÁN mostrar el correcto funcionamiento del sistema con casos de prueba provisto por los equipos y provistos ese día por la Cátedra. Para aprobar el Trabajo Práctico se DEBE cumplir TODAS las siguientes condiciones: o El material entregado DEBE estar completo (por ejemplo no se puede corregir si falta el informe o alguna clase) o Se utilizan únicamente las librería permitidas para los usos definidos. o DEBE ser correcta las cuestiones de entradas/salida no bloqueante. Por ejemplo las lecturas, escrituras y el establecimiento de nuevas conexiones DEBEN ser mediante suscripciones y no bloquearse. o DEBE ser correcta las cuestiones relacionadas a la lectura/ escrituras parciales. o Sumar CUATRO puntos de calificación sobre DIEZ puntos posibles.