bproxy/docs/enunciado.txt

232 lines
9.2 KiB
Plaintext

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].
[X] 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.
[X] 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.
[X] 6. implementar mecanismos que permitan recolectar métricas que
ayuden a monitorear la operación del sistema.
[X]A. cantidad de conexiones históricas
[X]B. cantidad de conexiones concurrentes
[X]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).
[X] 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).
[X] 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.
[X] 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.