bproxy/docs/enunciado.txt

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