El servidor web (VI): gestión de notificaciones.

En las últimas entradas hemos hablado de todo lo que pueden hacer cada uno de los diferentes tipos de usuarios que accedan a CygnusCloud. Sin embargo, nos falta por explicar una última página accesible a todos los tipos de usuarios, la página de muestreo de notificaciones.

Como algunas de las operaciones que ofrece CygnusCloud deben ser gestionadas por medio de peticiones, ya que su realización no es inmediata y no podemos dejar al usuario esperando durante un buen rato, es necesario ofrecer un sistema de notificaciones que permita a los usuarios consultar los mensajes que le envíe el sistema para comunicarle la finalización erronea o no de las peticiones enviadas.

Cuando un usuario reciba una nueva notificación, esta se le indicará mediante una etiqueta en la parte superior derecha de la página. Esta etiqueta permanecerá mientras el usuario no acceda a la página de notificaciones pendientes.

EtiquetaNotificaciones

Etiqueta de notificaciones pendientes

Una vez el usuario accede a la página de notificaciones pendientes, bien de forma manual accediendo desde la barra de menú o bien pulsando sobre la etiqueta, se le mostrará una lista con todas las notificaciones pendientes.

PaginaNotificaciones

Página de notificaciones pendientes.

Una vez leídas por el usuario, esta lista de notificaciones desaparecerá de la página, dejando sitio a las nuevas notificaciones pendientes que puedan ir apareciendo.

Con esta entrada, terminamos el paseo por toda la web de CygnusCloud. Esperamos que os haya resultado entretenida y que comentéis con cualquier duda que os haya podido surgir.

El servidor web (V): los administradores

En las anteriores entradas hemos contado todo lo que los estudiantes y profesores son capaces de hacer en CygnusCloud. Como quizás recordemos, cuando hablamos de los niveles en los que se dividía la aplicación web, mencionamos un tercer grupo de usuarios, los administradores. Los administradores son el grupo de usuarios que posee todos los privilegios. A continuación hablaremos de todo lo que un administrador puede hacer en CygnusCloud.

Al iniciar sesión como administrador, la primera página que se nos muestra es la página de arranque de máquinas virtuales ( accesible también mediante la opción Máquinas virtuales –> Arrancar). La forma de proceder en esta página, al igual que en las páginas de detención y apertura de máquinas en ejecución (Máquinas virtuales –> Detener y Máquinas virtuales –> Abrir), resulta similar al caso de las páginas de estudiantes ( explicadas aquí) con la diferencia de que, ya que un administrador puede gestionar cualquier máquina aunque no haya sido ejecutada por él, será necesario un dialogo de búsqueda que permita filtrar los resultados con los que actuar.

Por otra parte, el administrador también dispone de una página de edición de máquinas (opción Máquinas virtuales –> Editar), en la cual se pueden tomar ciertas decisiones sobre las máquinas registradas en el sistema tales como:

  • Eliminar la máquina seleccionada de toda la infraestructura
  • Eliminar la máquina seleccionada de un determinado servidor de máquinas virtuales
  • Desplegar automáticamente una máquina. Con esta opción, el sistema decidirá automáticamente sobre que servidores de máquinas virtuales debe desplegar la máquina seleccionada
  • Desplegar la máquina seleccionada en un servidor de máquinas virtuales concreto
Página de edición de máquinas virtuales para los administradores

Página de edición de máquinas virtuales para los administradores

En cuanto a la sección de servidores, el administrador puede crear y editar servidores por medio de las páginas correspondientes (opciones Administrar servidores –> Añadir servidor y Administrar servidores –> Editar servidor).

Para crear un nuevo servidor, el administrador debe indicar el nombre único con el que se referirá a dicho servidor, la dirección ip asociada a dicho servidor y el puerto de conexión. También debe indicarse si el servidor será capaz de albergar imágenes base o no.

La página de edición de servidores permite buscar alguno de los servidores de máquinas virtuales ya registrados en el sistema y modificar sus datos de conexión. Además, desde esta página, también es posible arrancar servidores apagados o eliminar el servidor  de la infraestructura.

En esta misma sección, el administrador puede acceder a la página de estado del sistema por medio de la opción Administrar servidores –> Estado del sistema. Esta página muestra un resumen sobre el consumo de recursos de los diferentes servidores y del repositorio en un momento concreto.

PaginaEstadoServidoresAdministrador

Página con la información de estado del repositorio de imágenes y el servidor con nombre Server1

Además, en esta sección, un administrador también puede detener toda la infraestructura accediendo a la página de detención de infraestructura (opción Administrar servidores –> Parar infraestructura).

En cuanto a la gestión de usuarios, los administradores pueden acceder a páginas que permiten registrar nuevos usuarios, eliminar usuarios existentes o matricular usuarios en los diferentes grupos de asignaturas. Para registrar un nuevo usuario (opción Administrar usuarios –> Añadir) es necesario indicar el correo electrónico asociado a dicho usuario, la contraseña, el tipo de usuario (estudiante, profesor o administrador) y, opcionalmente, una imagen de perfil.

PaginaEliminacionUsuarios

Página de eliminación de usuarios por parte de los administradores

Por último, un administrador tiene acceso a páginas de creación y eliminación de grupos de asignaturas. Una vez creado el grupo de asignatura, podrán matricularse en él cualquier profesor o estudiante registrado en CygnusCloud. Todas los grupos de asignaturas tienen asociados un número de plazas, a partir del cual no podrán matricularse más usuarios.

En la próxima entrada terminaremos de hablar de la web contando brevemente la gestión de notificaciones pendiente.

El servidor web (IV): los profesores

En la anterior entrada os contamos qué puede hacer un estudiante que acceda a CygnusCloud. En esta, os hablaremos de que pueden hacer los profesores registrados.

Una vez el profesor ha iniciado la sesión, la primera página que se le muestra es la página de arranque de máquinas virtuales. Esta página, al igual que la página de detención de máquinas (opción Máquinas arrancadas –> Detener máquina) y la página de apertura de máquinas arrancadas (opción Máquinas arrancadas –> Abrir máquina) funciona de forma similar a las páginas de estudiantes que se explicaron en la entrada anterior, por lo que no volverán a explicarse aquí.

El profesor también dispone de una página de creación de imágenes (opción Crear y editar –> Crear nueva máquina) en la cual puede crear nuevas máquinas a partir de una imagen base. Para ello el profesor deberá indicar un posible nombre para la imagen, una breve descripción y seleccionar sobre que imagen base desea crear la máquina. Las imágenes base viene caracterizadas por la memoria RAM, el número de CPUs y el tamaño en disco que se las ha otorgado.

PaginaCreacionMVProfesor

Página de creación de nuevas máquinas por parte de un profesor

Además de crear máquinas virtuales, un profesor también puede editar las máquinas que ya existan y que se encuentren asociadas a alguna de las asignaturas que imparte. En la opción Crear y editar –> Editar máquina se muestran dos tablas con las máquinas que pueden ser editadas. Dependiendo del estado de edición en el que se encuentre una determinada máquina virtual, aparecerá en una u otra tabla y se podrá aplicar sobre ella determinadas acciones.

PaginaEdicionMaquinasProfesor

Página de edición de máquinas existentes

En la imagen de arriba, aparecen seleccionadas dos imagenes en edición. La primera (Windows 7 ISBC) corresponde a una máquina que ha sido editada anteriormente, se ha detenido, pero todavía no se han aplicado los cambios para que sean visibles a los estudiantes. La segunda máquina (Debian AISO) corresponde a una máquina que se encuentra ejecutándose y en edición. Como podemos observar, ya que ambas máquinas se encuentran en diferente estado de edición, las acciones que se ofrecen para cada una son también diferentes.

Por último,  la opción Asociar asignaturas permite a los profesores asociar a cada máquina virtual en edición una de las asignaturas que este profesor imparte.

En la próxima entrada hablaremos acerca de todas las páginas accesibles para los usuarios registrados como administradores.

El servidor web (III): inicio de sesión y estudiantes

En la anterior entrada, os hablamos de la organización de la aplicación web de CygnusCloud en tres niveles. Como ya dijimos, el primer nivel permite distinguir entre los privilegios de los diferentes tipos de usuarios. En las próximas entradas os haremos un breve tour por la principales páginas que componen la web de CygnusCloud, distinguiendolas por el tipo de usuario que haya accedido.

La página inicial de CygnusCloud nos permite iniciar una sesión introduciendo el correo institucional que nos hayan dado y la contraseña asociada.

Además, desde esta página también es posible

  • visualizar los últimos tweets de la cuenta @CygnusCloud
  •  acceder a diferentes direcciones institucionales tales como el Campus Virtual o la página web de la UCM
  • acceder a la página Acerca de donde se muestra información acerca de que es CygnusCloud, para que sirve, que tecnologías utiliza…
PaginaInicioCygnusCloud

Página de inicio de sesión de CygnusCloud

Una vez iniciada la sesión como estudiante, la aplicación web nos muestra la página de arranque de máquinas virtuales. En ella el alumno puede seleccionar cualquiera de las máquinas asociadas a alguna de las asignaturas en las que se encuentra matriculado y arrancarla. También es posible acceder a esta página por medio del menú superior en la opción arrancar máquina

PaginaArranqueMVAlumno

Página de arranque de máquinas virtuales para un estudiante

Una vez arrancada, se abrirá una nueva pestaña donde el alumno podrá interactuar con la máquina virtual por medio del protocolo VNC. En ella el estudiante podrá trabajar en sus prácticas, así como descargar de Internet todo lo que necesite. Además también es posible ampliar el escritorio a pantalla completa o forzar el apagado usando los botones de la parte superior.

PaginaNoVNCAlumno

Escritorio remoto con máquina en ejecución

Una vez el estudiante haya terminado de trabajar en su práctica y haya guardado su trabajo en algún medio externo (Dropbox, Google Drive, correo electrónico…) podrá cerrar la máquina virtual simplemente apagandola.

No obstante, si el estudiante ha cerrado la pestaña sin apagar la máquina virtual o ha tenido algún problema crítico con la máquina virtual, podrá forzar la detención externamente por medio de la página de detención de máquinas (accesible desde el menú, opción máquinas arrancadas  –> detener máquina).

También es posible abrir de nuevo la pestaña con el escritorio arrancado para poder seguir trabajando en él accediendo a la opción máquinas arrancadas –> abrir máquina

En la próxima entrada os hablaremos de que puede hacer un profesor en CygnusCloud.

El servidor web (II): organización de las páginas

Como ya os comentamos en la entrada anterior, los usuarios interactuan con CygnusCloud por medio de una aplicación web. Para poder hacer frente al elevado número de páginas que ofrece CygnusCloud, hemos optado por estructurarlas en un sistema de tres niveles, que permite filtrarlas teniendo en cuenta los privilegios de acceso y la finalidad de cada página.

El primer nivel se centra en los privilegios de acceso. CygnusCloud agrupa los usuarios registrados en tres posibles tipos según los privilegios de que dispongan. Estos privilegios dan acceso a unas posibles páginas u otras. Los tres posibles tipos de usuarios son

  • Alumnos. Su rango de acción se limita a la posibilidad de arrancar, detener y abrir las máquinas asociadas a las asignaturas en las que se encuentran matriculados.
  • Profesores. Además de poder arrancar y detener las máquinas de las asignaturas que imparten, estos usuarios también pueden crear nuevas máquinas, así como editar las máquinas ya creadas previamente.
  • Administradores.  Este tipo de usuarios incluye, además de todas las acciones disponibles para el resto de usuarios, la posibilidad de gestionar los usuarios y las asignaturas registradas en el sistema.

En el segundo nivel las páginas se encuentran agrupadas teniendo en cuenta los aspectos comunes para un tipo de usuario concreto. Así, en este nivel, podemos encontrar un grupo destinado a la gestión de máquinas virtuales, o a la gestión de usuarios, asignaturas..

Por último, el tercer nivel, incluye cada una de las páginas concretas que limitan las funcionalidades de los grupos del segundo nivel que las contienen. Así, para el grupo de gestión de máquinas, en este nivel encontraremos una página de arranque de máquinas, una de detención …

Estos tres niveles pueden detectarse en la web con bastante facilidad. Cuando el usuario inicia sesión, solo se le da acceso a las páginas del grupo de usuario al que pertenezca.

Barra de menú con las secciones accesibles para los estudiantes

Barra de menú con las secciones accesibles para los estudiantes

La barra de menú superior, presente en todas las páginas de usuarios registrados, muestra las diferentes secciones del segundo nivel a las cuales el usuario tiene acceso.

Barra de menú con las secciones accesibles para los profesores

Barra de menú con las secciones accesibles para los profesores

Además, al desplazar el ratón por cada una de estas secciones se despliega un submenú con las diferentes páginas del tercer nivel asociadas a esta sección.

Barra de menú con las secciones accesibles para los administradores

Barra de menú con las secciones accesibles para los administradores

En las tres próximas entradas os hablaremos de las páginas accesibles para cada uno de los tipos de usuarios que forman parte del primer nivel.

El servidor web (I): el framework web2py

¡Hola a todos!

Ahora que ya os hemos contado como funciona la infraestructura de CygnusCloud, os hablaremos sobre que es necesario para poder interactuar con ella.

El servidor web es el encargado de mantener la aplicación web de CygnusCloud, así como de enviar las peticiones de los usuarios a la infraestructura. Gracias a que es posible acceder a CygnusCloud por medio de una página web, los ordenadores desde los cuales los usuarios quieran utilizar CygnusCloud solo necesitarán tener un navegador web instalado, con un motor de JavaScript medianamente actualizado (incluido en las últimas versiones de Google Chrome, Mozilla Firefox, Internet Explorer o Safari).

Para poder implementar una aplicación web que nos facilitase en la medida de lo posible la forma de reforzar la seguridad frente a posibles ataques externos y  de estructurar el código, y nos permitiese centrarnos en la implementación de todas las páginas necesarias, optamos por utilizar algún framework web. Tras informarnos y evaluar las posibles ventajas y desventajas optamos por utilizar web2py.

web2py es una plataforma web de código abierto, escrita en python, que permite un ágil desarrollo de aplicaciones web seguras, gestionadas por medio de bases de datos.

Las principales características que nos hicieron decantarnos por él son las siguientes:

  • es ligero y rápido
  • ofrece una estructura sencilla, basada en el modelo vista-controlador, que permite a los usuarios aprender sobre el desarrollo web sin comprometer la funcionalidad del sistema.
  • no necesita instalación ni configuración.
  • sus actualizaciones se realizan de forma incremental, permitiendo una total compatibilidad entre las nuevas versión y las aplicaciones realizadas utilizando versiones antiguas.
  • ataca de manera proactiva las cuestiones de seguridad más relevantes
  • ofrece una interfaz administrativa que permite simplificar la creación y gestión de las aplicaciones.
  • dispone de bastante documentación, así como foros de ayuda.

Si queréis saber más sobre web2py, podéis acceder a su página  y descargaros su completo manual de usuario

En las próximas entradas os daremos una vuelta por la web de CygnusCloud y os mostraremos todo lo que pueden hacer los estudiantes, profesores y administradores registrados.

Actualización: ¿qué ha pasado durante el último mes?

¡Hola a todos!

Tras un mes muy intenso en el que hemos dormido muy poco y trabajado mucho, al fin hemos sacado tiempo para contaros qué ha sido de CygnusCloud.

En primer lugar, CygnusCloud recibió el Premio al Mejor Proyecto Comunitario en la 7ª Edición del Concurso Universitario de Software Libre. Aunque tarde, desde aquí queremos dar (de nuevo) las gracias a los miembros del jurado por fijarse en nuestro humilde proyecto.

Premiados en la Séptima Edición del CUSL. El equipo de CygnusCloud aparece en la segunda fila, a la izquierda. Fuente: Concurso Universitario de Software Libre

Premiados en la Séptima Edición del CUSL. El equipo de CygnusCloud aparece en la segunda fila, a la izquierda. Fuente: Concurso Universitario de Software Libre

El viernes 24 de Mayo, participamos en la final nacional del CUSL. Si queréis, podéis descargaros las diapositivas de nuestra presentación desde aquí.  Además, algunos profesores de la Universidad de Granada nos comentaron que van a evaluar la hipotética implantación de CygnusCloud durante el próximo curso académico.

Por otra parte, durante este mes hemos estado terminado de implementar e integrar con bastante éxito toda la funcionalidad del proyecto. La semana que viene terminaremos dos versiones candidatas, y el día 25 de Junio publicaremos la versión final.

Además, también hemos terminado de escribir la memoria del proyecto, en la que podréis encontrar toda la documentación que hemos generado a lo largo del desarrollo de CygnusCloud (incluyendo el diseño completo y el manual de usuario).

Durante los próximos días, iremos terminando, comentando, licenciando y moviendo el código de la versión final a la rama master de nuestro repositorio. Además, también retomaremos nuestro repaso de CygnusCloud por donde lo dejamos: el servidor web.

Si queréis ver cómo termina el desarrollo de CygnusCloud, en el que llevamos metidos cerca de un año, ¡no os perdáis las próximas entradas!

CygnusCloud, proyecto finalista de la séptima edición del CUSL

¡Hola a todos!

Ayer recibimos una fantástica noticia: CygnusCloud es finalista a nivel nacional de la Séptima Edición del Concurso Universitario de Software Libre. Para no causar problemas a la organización del concurso, hemos preferido esperar a que hicieran el anuncio oficial antes de contároslo.

Desde aquí, queremos dar las gracias a los miembros del jurado por fijarse en nuestro humilde proyecto. También queremos daros las gracias a todos los que nos habéis estado siguiendo a través del blog. Vuestras visitas, vuestros comentarios y vuestras descargas son el mejor estímulo para nosotros.

El próximo 23 de mayo viajaremos a Granada para participar junto con el resto de nuestros compañeros finalistas en la Fase Final del concurso, que tendrá lugar los días 23 y 24 de mayo en la Escuela Técnica Superior de Ingenierías Informática y Telecomunicación de la Universidad de Granada.

Desde aquí, os animamos a asistir a las charlas y ponencias que se van a celebrar, entre las que estará la de CygnusCloud.

Comunicaciones de red en CygnusCloud (III): el módulo de comunicaciones

¡Hola a todos!

En esta entrada os hablaremos, de forma muy general, del módulo de comunicaciones de CygnusCloud. Para no aburriros con demasiados detalles, no os contaremos cómo interactuamos con Twisted ni os hablaremos de toda la jerarquía de clases de este módulo.

Lo primero que debe hacer el módulo de comunicaciones es

  • convertir la información a enviar en una secuencia de bytes, y
  • procesar las secuencias de bytes recibidas para extraer los números enteros y de punto flotante, valores booleanos, strings,… que contienen.

Para que estos procesos sean totalmente transparentes a los usuarios, estos no envían y reciben bytes: envían y reciben paquetes. Serán los paquetes los encargados de manipular la secuencia de bytes. Así,

  • cuando se lee un valor de un paquete, se extrae de la secuencia de bytes, se convierte al tipo correspondiente y se le devuelve al usuario. Por ejemplo, si leemos un entero de un paquete, se extraen sus bytes de la secuencia, se utilizan para construir el número entero y se devuelve el número obtenido.
  • cuando se escribe un valor en un paquete, se convierte en una secuencia de bytes y se inserta al final de la secuencia de bytes del paquete. Por ejemplo, al escribir un booleano en un paquete, se añade un byte a cero o a uno al final de la secuencia de bytes del paquete.

Pero los paquetes, por sí mismos, no sirven de nada: necesitamos una conexión de red por la que enviarlos y recibirlos. Las conexiones de red son objetos que interactúan con Twisted para enviar y recibir paquetes, y también para detectar eventos como la desconexión inesperada de una máquina.

Con las conexiones de red, ya podemos intercambiar información entre distintas máquinas, pero el diseño de Twisted hace que necesitemos algo más. Los paquetes recibidos se procesan dentro del bucle reactor de Twisted, lo que significa que, mientras se está procesando un paquete, no se detectarán los cambios que se produzcan en el resto de sockets.

Esto es un problema gordo. Por ejemplo, no podemos permitirnos que el servidor de máquinas virtuales ignore al servidor de cluster durante el lento proceso de arranque de una máquina virtual. Para resolverlo, los paquetes de cada conexión se procesan en un hilo independiente. Así, estos “cuelgues” no se producirán.

Por otra parte, también nos interesa que el tráfico de todas las conexiones se vuelque de forma ordenada a la red. Por ejemplo, con independencia de la conexión por la que se envíe, un paquete que informa de un error crítico debe  enviarse antes que todos los demás. Para hacer esto posible, las conexiones no envían directamente los paquetes: estos se envían en un hilo dedicado, y compartido por todas las conexiones activas.

Lo último que nos falta para terminar el módulo es una fachada, el gestor de red, que permite crear y borrar conexiones, enviar y recibir paquetes a través de ellas y también activar y desactivar las comunicaciones de forma muy sencilla.

Con esto, ya sabéis, de forma general, cómo funciona nuestro módulo de comunicaciones. Evidentemente, el diseño es mucho más complejo, pero no hemos querido abrumaros con demasiados detalles.

Si queréis saber cómo interactuamos con Twisted y cómo funciona todo el módulo, podéis descargaros una versión casi definitiva de su documentación en la sección Manuales. Además, podréis encontrar todo el código fuente aquí.

Actualización: podéis encontrar todo el código fuente del módulo de comunicaciones en este repositorio. Además, su documentación definitiva está disponible en el capítulo 4 de la memoria del proyecto.

Comunicaciones de red en CygnusCloud (II): si te ofrecen Twisted… dí no

¡Hola a todos!

Como vimos en la última entrada, para comunicar equipos a través de una red sólo necesitamos manipular sockets.

Aunque la librería estándar de Python nos deja manipular sockets de forma independiente de la plataforma, la forma de utilizarlos sigue siendo bastante engorrosa: tenemos que muestrearlos periódicamente para determinar si nos han enviado algo, recordar qué sockets están asociados a cada comunicación, convertir la información a enviar en una secuencia de bytes, procesar las secuencias de bytes recibidas…

Por tanto, para tener el módulo de comunicaciones funcionando cuanto antes, resulta imprescindible utilizar una librería que nos deje manipular sockets. Entre todas las librerías de este tipo escritas en Python, hubo una que llamó poderosamente nuestra atención: Twisted.

Twisted es una librería de red basada en eventos. Y no es una librería de red más: es el estándar “de facto” para comunicar aplicaciones Python a través de una red. Está tan extendida que se utiliza en prácticamente todas las instalaciones de Linux e incluso en Mac OS X.

En Twisted, el establecimiento de conexiones y el envío de información son síncronos. Es decir, si queremos conectarnos a una máquina, llamamos, desde nuestro código, a un método que crea la conexión; si queremos enviar datos a otra máquina, también.

En cambio, la detección de desconexiones y la detección de errores (como, por ejemplo, las desconexiones inesperadas) son totalmente asíncronos. Es decir, el código de la librería avisa a nuestro código cuando se reciben datos, cuando una máquina se desconecta,…

Para “avisar” a nuestro código, Twisted define una serie de interfaces (a la que llama protocolos) y utiliza un bucle reactor, que muestrea periódicamente el estado de los sockets. En una imagen, el funcionamiento de la parte asíncrona de Twisted podría resumirse así:
bucle-reactorHasta aquí todo parece muy bonito y convincente, ¿verdad? Entonces… ¿a qué se debe el título de la entrada? Básicamente, a tres razones: a la pésima documentación de Twisted, a sus enormes dimensiones y a las regresiones que hay entre versiones consecutivas.

En primer lugar, Twisted está pésimamente mal documentada. No es que falte la documentación de unos cuantos métodos: la propia documentación se contradice a sí misma. Tras cuatro meses pegándonos con esta librería, hemos llegado a una conclusión: una cosa es lo que la documentación dice… y otra muy distinta es lo que el código de Twisted hace.

En la mayoría de casos, la mejor forma de conseguir información es utilizando la  función dir() de Python, que devuelve la lista de atributos de un objeto. Es ahí donde tenéis que empezar a buscar lo que necesitáis, y no en la documentación oficial de Twisted.

Por otra parte, Twisted es gigante. Esto, unido a la fantástica documentación, nos ha dado muchos más quebraderos de cabeza: para ubicar lo que necesitábamos en todo el “zoo” de clases de Twisted, muchas veces hemos tenido que recurrir al propio código fuente de la librería. Por suerte, Twisted está escrita en Python y los “binarios” que se distribuyen contienen su código fuente.

Además, también hay regresiones considerables de unas versiones a otras. Por ejemplo, en la versión que se distribuye con Ubuntu 12.04 las conexiones a la IP loopback funcionan perfectamente; en la última versión, la 13, sólo funcionan si se establecen en cierto orden.

Como supondréis, programar el módulo de comunicaciones no ha sido fácil. Es más, estamos convencidos de que, si hubiésemos manipulado sockets directamente, habríamos tardado menos.

En cualquier caso, ahora conocemos perfectamente las “tripas” de Twisted. Es más, nuestro módulo de comunicaciones se ha convertido en una librería de red multiplataforma y de propósito general, válida para comunicar cualquier tipo de aplicaciones Python.

En la próxima entrada, os presentaremos las ideas básicas de este módulo. Además, os colgaremos una sección de la memoria en la que explicamos detalladamente el funcionamiento de Twisted y el diseño de este módulo.

Si queréis echarle un vistazo a este módulo (o incluso utilizarlo), tenéis todo el código fuente aquí.