2012-08-22 / The Work Department
En los últimos años, el Departamento de Trabajo ha participado activamente en la construcción de redes inalámbricas comunitarias en Detroit. Hemos experimentado con diferentes tipos de hardware y software, y hemos ayudado a barrios a construir redes útiles para compartir la conectividad a Internet y proporcionar el intercambio local de archivos. Algo que no hemos tenido muchas oportunidades de explorar, no obstante, es la construcción de sistemas más elaborados que aprovechen las características únicas de las redes de mesh. Como hemos trabajado mediante otras partes del proyecto Commotion, hicimos una lluvia de ideas para aplicaciones de mesh inalámbricas. Notamos que nuestras ideas a menudo replicarían servicios web — existentes, por ejemplo, un servidor local de archivos para música o películas, o un tablero local de mensajes para discusiones comunitarias. Empezamos a cuestionar qué haría una aplicación inalámbrica comunitaria más atractiva que el uso de una aplicación centralizada basada en el Internet. Concordamos que no sería suficiente ofrecer a alguien la simple satisfacción de saber que sus datos son descentralizados… tendría que haber algunos otros beneficios al usar una aplicación local. ¿Cuáles serían estos beneficios? ¿Qué tiene de especial la arquitectura de una red mesh inalámbrica comunitaria? Al reflexionar sobre estas preguntas, consideramos lo que se provee para estas redes — anteriormente, mencioné que las redes proporcionan una conexión compartida a Internet y compartir archivos locales, pero eso es sólo una parte de la historia. Estas redes también ofrecen algo mucho más grande: se convierten en instituciones comunitarias. A diferencia del hardware de Comcast que está atornillado a un poste de electricidad fuera del alcance de la mano, nuestro equipo inalámbrico de comunidad vive en nuestros porches, en gallineros, en nuestros campanarios, y al lado de nuestros escritorios. Cada pieza del equipo tiene una historia detrás. Sabemos quién sostenía la escalera mientras estaba siendo instalado y quién prestó su martillo perforador para que el cable se deslizará por ahí. La dirección IP de un router de una red mesh inalámbrica comunitaria es más que un número de 32 bits. Tiene una historia y un significado. ¿Cómo podríamos construir aplicaciones que reflexionen y mejoren esto? Tuve la buena fortuna de conocer a Adam Magaluk en el hackerspace en Detroit, OmniCorpDetroit. Adam trabaja en sistemas inalámbricos mesh en Illuminating Concepts, y está profundamente interesado en OLSR y sistemas embebidos. Los dos somos jóvenes programadores y compartimos una preferencia por los sistemas modulares y descentralizados. Durante nuestras conversaciones iniciales e investigación, terminamos favoreciendo el desarrollo de aplicaciones basadas en navegadores web. De esta manera, las personas que quisieran utilizar una aplicación no tendrían que descargar nada. Ya que los navegadores de hoy en día tienen capacidades de mensajería de streaming ligeros con WebSocket, tendríamos una gran flexibilidad en el desarrollo de aplicaciones. Para construir una aplicación basada en navegador web, podemos comenzar por limitar la cantidad de trabajo que el servidor hace a su mínima expresión. En la circunstancia de una aplicación de chat, podemos decir que el servidor debe simplemente mantener un registro de quién está conectado a una sesión de chat (en una especie de modelo de suscripción) y luego, a medida que se publican mensajes, transferir los mensajes de la editorial a la suscriptores. Limitando las funciones de cada nodo mesh a pasar mensajes y hacer el seguimiento de los clientes conectados, termina siendo beneficioso en dos formas: conserva los recursos informáticos y fomenta el desarrollo de aplicaciones descentralizadas. Ya que la mayoría de los routers inalámbricos comunitarios son de bajo poder, los dispositivos de bajo costo trabajan con memorias MIPS CPUs y 4-16GB, el beneficio anterior es claramente atractivo. El último beneficio es más complejo — ¿realmente necesitamos una aplicación completamente descentralizada? ¿Por qué no podemos solo tener un poco de almacenamiento de nodos locales? Seguramente haría las cosas más sencillas si pudiéramos tener un cache de datos locales en lugar de intentar desarrollar un sistema de almacenamiento peer-to-peer, pero por ahora, tendremos que acoger esta limitación cuando diseñemos aplicaciones. Para comenzar a experimentar con los conceptos básicos de los sistemas de mensajería ligeros que pueden trabajar con el hardware de una red inalámbrica comunitaria, hemos construido una aplicación de ejemplo para proporcionar un servicio WebSocket a los clientes conectados a un punto de acceso Commotion. Este servicio puede utilizarse para cualquier cosa en la red, pero en nuestra primera aplicación ejemplo, se utiliza para una aplicación web servida de un LuCI URI accesible públicamente ligado a la página splash. La aplicación provee una interfaz simple para chatear con otras personas que se han conectado al sistema de chat websocket del nodo local. Gracias al trabajo de Hans-Christoph Steiner (de The Guardian Project) en el jsoninfo plugin, OLSRd puede proveer fácilmente alguna información de red útil como un objeto json para aplicaciones web. Sobre la capa de la red, nuestro servidor de mensajes WebSocket puede proveer datos acerca de los clientes conectados y posiblemente otra información en el futuro. Después de acostumbrarse al servidor WebSocket, sus restricciones resaltadas, y el campo de juego de la red mesh, puedes comenzar a imaginar varias situaciones en las que la mensajería local podría ser interesante. Con una idea en mente, un desarrollador puede saltar fácilmente hacia un ambiente de desarrollo de aplicaciones web familiar. Si has usado cosas como WebSockets o socket.io, ya entiendes los conceptos básicos de la escritura de una aplicación de red mesh usando estos bloques de construcción. A medida que construyamos más aplicaciones en la plataforma, ofrecerá más opciones para los desarrolladores. Próximos pasos Actualmente, el sistema proporciona un servicio de mensajería que no utiliza conexiones mesh de nodo-a-nodo. Tal como está, podemos desarrollar algunas aplicaciones interesantes y útiles, pero sin duda hay mucho que ganar al añadir funcionalidad y, posiblemente, modernizando las cosas en el interés de la seguridad o la privacidad. Nuestra próxima tarea importante es comenzar a experimentar con sistemas que- permiten a nodos vecinos suscribirse a las conexiones entre ellos. Para utilizar la aplicación del chat como un ejemplo de cómo se podría utilizar esto: un participante del chat podría ser capaz de iniciar una conversación con personas conectadas a su propio nodo mesh y con sus vecinos próximos, o algún otro número arbitrario de hops. También nos gustaría experimentar con implementaciones sencillas de almacenamiento compartido / distribuido. Una vez más, utilizando el sistema de chat como una ilustración, podríamos tener participantes del chat almacenando registros de chat y ofreciéndolos a nuevos participantes que emitan una solicitud de los últimos N minutos de una conversación. Hay demasiado trabajo de almacenamiento distribuido para que podamos referenciar, por su puesto, ¡así que tenemos mucho trabajo por delante! Además de mejoras y aplicaciones en el sistema de mensajes mismo, tenemos muchas ideas para las aplicaciones actuales. Recientemente hemos estado haciendo prototipos de juegos que podrían usar redes mesh de un barrio o multi-comunitarios como campo de juego. Hemos encontrado que hacer prototipos y lluvia de ideas de juegos es un proceso revelador: ayuda a explicar las entradas y salidas de la tecnología a la gente, y también presenta retos claros para crear metas obvias y alcanzables dentro de las limitaciones de la tecnología. Estaremos compartiendo algunos estilos de juego como “captura la bandera” que utiliza un sistema “meshaging” durante las próximas semanas.