Universidad Carlos III de Madrid Departamento de Ingeniería Telemática

Práctica Redes de Ordenadores II: Implementación de un cliente IRC

 INTRODUCCIÓN

Nota: modificaciones para Septiembre 2011 resaltadas en rojo.

Esta práctica consiste en desarrollar un cliente del protocolo IRC. El protocolo IRC, Internet Relay Chat, es un protocolo estándar del IETF para comunicación en tiempo real basado en texto, que permite a los usuarios unirse y comunicarse en grupos de discusión, llamados canales, y además permite también, entre otras cosas, mensajes privados entre dos usuarios y transferencia de ficheros. El sistema IRC, inspirado en otro sistema llamado Bitnet, fue creado por Jarkko Okarinen en 1988. Ha evolucionado y se ha complementado con nuevas capacidades hasta nuestros días, como cifrado, transferencia de ficheros, comandos adicionales, etc... y aunque su uso ha decaído debido al uso de las redes sociales y otros sistemas de mensajería instantánea, se sigue usando en entornos de desarrollo de software y otros ámbitos.

La práctica debe desarrollarse en lenguaje C ó lenguaje C++ (consulte las aqui las librerías que se permiten usar) sobre sistema operativo Linux y debe funcionar en los ordenadores de los laboratorios docentes de Ingeniería Telemática, donde se realizará la corrección presencial. Recordad que para poder trabajar en estos laboratorios debeis tener una cuenta abierta en el departamento, en la página principal de la asignatura encontrareis información sobre este procedimiento.

Existen varias máquinas a las que os podeis conectar de forma remota (ssh): monitor01.lab.it.uc3m.es a monitor06.lab.it.uc3m.es. Detalles sobre cómo trabajar remotamente se pueden encontrar aqui.

 OBJETIVOS

Los objetivos que se pretenden alcanzar con el desarrollo de esta práctica son los siguientes:

  1. Enfrentarse a la implementación de un protocolo real, partiendo de su especificación original (RFC).
  2. Conocer protocolos de comunicación en tiempo real basados en texto.
  3. Reforzar conocimientos teóricos de algunos de los protocolos que hemos visto en la asignatura.
  4. Adquirir conocimientos de programación de sockets.
 ENUNCIADO

El protocolo IRC está especificado a través de una serie de documentos estándar del IETF (RFC 2810, RFC 2812 y otros; véase sección recursos). Es necesario desarrollar un cliente IRC que cumpla con las especificaciones de dichos documentos y ciertas simplificaciones descritas abajo. También es obligatorio implementar ciertas extensiones para transferencia de ficheros usando los protocolos DCC y CTCP.

No hay que desarrollar un servidor IRC, pero sí hay que instalarse uno en la cuenta de cada alumno para hacer pruebas con el cliente. Se ha elegido el servidor ngircd por su amplia documentación, simplicidad y facilidad de uso. Instrucciones de cómo instalar el servidor ngircd se pueden encontrar aqui:



Se pide por tanto implementar un cliente IRC que cumpla con las especificaciones del estándar IRC (veánse RFC) y con las siguientes consideraciones:

  • Ejecutable y parámetros: el ejecutable se llamará ircc y debe soportar los parámetros que se indican a continuación. Si algunos no se proporcionan, el programa hará automáticamente lo posible y lo que no pueda por falta de datos, esperará a los comandos interactivos del usuario. Véase la página de manual de ircc para detalles.

    ircc [-l] [-s host:port] [-n nickname] [-c channel] [-d]

    • -s server:port: nombre y puerto del servidor IRC.
    • -n nickname: nick del usuario.
    • -c channel: canal al que se conecta el usuario.
    • -d: modo depuración. Mostrará trazas adicionales para la depuración del programa.
    • -l: modo legacy. El comando DCC SEND no incluirá el parámetro "tamaño de fichero" (Modificación para la convocatoria de septiembre).

  • Ejemplos y trazas: véase también página de manual de ircc.

  • Notas y simplificaciones a la práctica:

    1. Todos los mensajes deben mostrarse por la salida estándar, excepto los mensajes de error, que deben mostrarse por la salida de error estándar.

    2. No es necesario implementar todos los mensajes especificados en la RFC 2812. Al menos los siguientes sí son obligatorios para aprobar la práctica: nick (3.1.2), user (3.1.3), quit (3.1.7), join (3.2.1), part (3.2.2), list (3.2.6), mensajes privados (3.3.1), who (3.6.1), ping (3.7.2), pong (3.7.3) y los mensajes necesarios para la transferencia de ficheros.

    3. Los clientes IRC sólo se conectarán a un canal (no deberán conectarse a varios canales simultáneamente) y no intercambiarán más de un fichero a la vez ni servirán más de un fichero a la vez.

    4. Los clientes IRC no enviarán mensajes al canal usando mensajes privados, ya que éstos se dedicarán únicamente a la transferencia de ficheros.

    5. Es recomendable probar con un cliente libre, como ircII, BitchX, Chatzilla ó cualquier otro, realizar capturas con wireshark y verificar los mensajes cliente-servidor intercambiados. Se puede también probar con telnet (telnet nombre_maquina 6667) ya que el protocolo IRC es textual. Note que los clientes ircII y BitchX están instalados en los laboratorios, no es necesario que los instale por su cuenta.

    6. Es obligatoria la lectura de las FAQ para una correcta interpretación de la práctica.

    7. El puerto en el que el programa ircc abrirá el servidor DCC es 8000 + número de grupo, por ejemplo, el grupo 101 usará el puerto 8101 para su servidor DCC

    8. Lea los criterios de evaluación indicados en el apartado siguiente.
 EVALUACIÓN

La evaluación de la práctica se realizará de forma presencial y su nota tendrá un peso del 40% sobre la nota final de la asignatura. Para que se haga media con el examen teórico debe obtenerse una nota superior o igual a 5. La nota de la práctica, siempre que esté aprobada, se mantendrá para la convocatoria de Septiembre de 2011. Además, en caso de aprobarse en la convocatoria de Febrero, esta nota podrá conservarse hasta el siguiente curso académico 2011/12.

Fechas importantes:

  • 10 de Enero de 2011 a las 23:55: Entrega por Aula Global 2

  • 20 de Enero de 2011: Examen presencial en laboratorio.

  • 28 de Mayo de 2011: Convocatoria anticipada. Entrega por Aula Global 2.

  • 31 de Mayo de 2011: Convocatoria anticipada. Examen presencial en laboratorio.

  • 8 de Septiembre de 2011: Convocatoria de Septiembre. Entrega por Aula Global 2.

  • 15 de Septiembre de 2011: Convocatoria de Septiembre. Examen presencial en laboratorio.


Condiciones de entrega:
  • Se debe entregar un único fichero en formato zip. El nombre del fichero será grupoXXX.zip groupXXX.zip, donde XXX será el número de vuestro grupo de prácticas, por ejemplo grupo101.zip group101.zip

  • El fichero zip contendrá los siguientes ficheros:
    • Los ficheros .c, .cc y .h necesarios para generar el ejecutable de la práctica.
    • Un fichero Makefile.
    • Un fichero README con el nombre y correo de los integrantes del grupo y, de forma opcional, unos breves comentarios sobre la práctica: aspectos adicionales a los del enunciado que se implementen, o cualquier tema fuera de lo común que debamos tener en cuenta durante la corrección (el formato de este fichero es libre).

  • El zip y el Makefile deben ser tales que, habiendo copiado el zip a un directorio vacío, la siguiente secuencia de comandos genere un fichero binario ircc en ese mismo directorio listo para ejecutar:
    • unzip grupo101.zipunzip group101.zip
    • make

  • El programa no debe tener errores de compilación. Las condiciones obligatorias de compilación se pueden consultar en la FAQ.

  • Es recomendable que el ejecutable no tenga fugas de memoria. Se puede comprobar con valgrind (véanse la sección sobre valgrind en la FAQ para más detalles). Aunque no es obligatorio que la práctica esté libre de fugas de memoria, si limitará la nota máxima a un 7.
 MODIFICACIONES PARA LA CONVOCATORIA EXTRAORDINARIA

Fecha de entrega:
  • La entrega por Aula Global 2 será en las fechas indicadas arriba.
Modificaciones en las condiciones de entrega:
  • El nombre del fichero entregable será groupXXX.zip en lugar de grupoXXX.zip, donde XXX será el número de vuestro grupo de prácticas, por ejemplo group101.zip.
Modificaciones en el enunciado de la práctica:
  • El cliente debe ser capaz de ofrecer y descargar varios ficheros simultaneamente. Todos los ficheros ofrecidos se sirven desde un único puerto, que será el del puerto DCC correspondiente a tu grupo, por ejemplo el 8101. Cuando se ofrezcan varios ficheros a un mismo cliente o a varios clientes en la misma máquina, se les irán entregando según vayan llegando las conexiones, en el mismo orden en que se hicieron las ofertas, por ejemplo:
    Servidor ofrece a cliente1 el fichero file1 desde 1.2.3.4:8101
    Servidor ofrece a cliente2 el fichero file2 por 1.2.3.4:8101
    Servidor ofrece a cliente1 el fichero file3 por 1.2.3.4:8101
    Cliente2 se conecta a 1.2.3.4:8101 y se le envía el file2
    Cliente1 se conecta a 1.2.3.4:8101 y se le envía el file1
    Cliente1 se conecta a 1.2.3.4:8101 y se le envía el file3
  • El cliente debe aceptar un comando DCC SEND que no contenga el tamaño del fichero enviado, de acuerdo con la especificación del protocolo DCC. Para probar esto, se añadirá una nueva opción "-l" de línea de comandos al programa. Cuando se arranque ircc con dicha opción, la orden /send enviará un comando DCC sin el parámetro opcional "size". Independientemente de si esta opción se active o no, el programa siempre debe soportar la llegada de un comando DCC SEND sin dicho parámetro.

  • El servidor DCC debe autenticar las descargas por IP. Es decir, un fichero solo podrá ser descargado desde un cliente que resida en la IP a la que el fichero fue ofrecido.

  • Se debe implementar un nuevo comando /dccinfo, que muestra el estado de las subidas y descargas activas. Este nuevo comando no tiene argumentos. Ejemplos:
    • En caso de no tener activa ninguna subida ni descarga DCC:
      > /dccinfo
      > 
    • En caso de tener 2 descargas activas:
      >/dccinfo
      downloading Batman.mpg from 192.168.1.1:8101 (1024 bytes)
      downloading Superman.avi from 192.168.1.1:8101 (2048 bytes)
      > 
    • En caso de tener varias subidas y descargas activas:
      >/dccinfo
      downloading Batman.mpg from 192.168.1.1:8101 (1024 bytes)
      downloading Superman.avi from 192.168.1.1:8101 (2048 bytes)
      uploading Spiderman.avi to 163.117.15.10:34752 (5230/50000 bytes)
      uploading Spiderman2.avi to 163.117.15.10:34764 (4234/60000 bytes)
      uploading Spiderman3.avi to 127.0.0.1:43756 (2340/70000 bytes)
      > 

      El orden de las líneas de salida del comando /dccinfo es irrelevante.

      Entre paréntesis se muestra el número de bytes que se llevan descargados y en el caso de las subidas, se muestra también el tamaño total del fichero.

 RECURSOS Y ENLACES

Libros

  • W. R. Stevens: "Unix network programming".Volume 1.Networking APIs-Sockets and XTI (L/S 004.451.9 UNIX STE )

Información sobre sockets

RFC


Localización | Personal | Docencia | Investigación | Novedades | Intranet
inicio | mapa del web | contacta