Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingenier´ıa en Inform´atica Implementaci´on de una pasarela entre el protocolo RT-WMP y TCP/IP Rub´en Dur´an Balda Director: Danilo Tardioli Ponente: Jos´e Luis Villarroel Salcedo Departamento de Inform´atica e Ingenier´ıa de Sistemas Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza Curso 2011/2012 Noviembre de 2011 A mis padres y mi hermana. ´ Indice general 1 Introducci´on 1 1.1 Contexto ........................................ 1 1.2 Objetivos ........................................ 2 1.2.1 Ejemplos de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Otrosobjetivos................................. 3 1.3 Estructuradelamemoria ............................... 4 2 Trabajo previo 5 2.1 Visi´ongeneral...................................... 5 2.2 ProtocoloRT-WMP .................................. 6 2.2.1 Visi´ongeneral.................................. 6 2.2.2 Fasesdelprotocolo............................... 6 2.2.3 Matriz de calidad del enlace (LQM) . . . . . . . . . . . . . . . . . . . . . 7 2.2.4 Extensiones................................... 8 2.2.5 Arquitectura de la implementaci´on . . . . . . . . . . . . . . . . . . . . . . 8 3 An´alisis y dise˜no del sistema 11 3.1 An´alisis ......................................... 11 3.2 Introducci´on a la soluci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Espaciodekernel................................ 12 3.3 Descripci´ondetallada.................................. 13 3.3.1 Visi´onglobal .................................. 13 3.3.2 Modificaciones al controlador . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3 Adaptaci´on de RT-WMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.4 Pasarela..................................... 18 3.4 Desarrollodelproyecto................................. 20 3.4.1 Interfaz sobre ath5k raw . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.2 Adaptaci´on de RT-WMP como m´odulo del kernel . . . . . . . . . . . . . . 21 3.4.3 Integraci´on de los tres m´odulos . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.4 Ampliaci´on de las funcionalidades de la pasarela . . . . . . . . . . . . . . 22 3.4.5 Acceso directo a RT-WMP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4.6 Ficheros en /proc de RT-WMP . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.7 Compilaci´on conjunta de los 3 m´odulos . . . . . . . . . . . . . . . . . . . 25 4 Evaluaci´on y experimentos 27 4.1 Entornodepruebas................................... 27 4.2 Pruebas en el laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.1 Comparativa entre linux us y linux ks . . . . . . . . . . . . . . . . . . . . 27 4.2.2 Equidad(Fairness)............................... 29 I ´ INDICE GENERAL ´ INDICE GENERAL 4.2.3 PruebasconSkype............................... 30 4.2.4 Pruebacompleta................................ 30 4.3 Pruebadecampo.................................... 30 4.3.1 Preparaci´on................................... 30 4.3.2 Pruebas..................................... 30 5 Conclusiones y trabajo futuro 33 5.1 Conclusiones ...................................... 33 5.2 Trabajofuturo ..................................... 34 A Manual de uso 35 A.1 Compilaci´on e instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.1.1 Previos ..................................... 35 A.1.2 Configuraci´on.................................. 35 A.1.3 Compilaci´on .................................. 36 A.1.4 Instalaci´on ................................... 36 A.2 Configuraci´on...................................... 36 A.2.1 RT-WMP.................................... 36 A.2.2 Ath5krawllcom................................ 37 A.2.3 Tr´afico de la pasarela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A.3 Puesta en funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 A.3.1 Funcionamiento aut´onomo . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 A.3.2 Coninterfaz................................... 38 B Comparativa entre Ioctl y Procfs 39 B.1 Mediciones ....................................... 39 B.2 An´alisis ......................................... 40 C Resultados de las pruebas 41 C.1 Anchodebanda .................................... 41 C.2 Duraci´on de una iteraci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.3 Restodepruebas.................................... 42 Bibliograf´ıa 43 ´ Indice de figuras 45 ´ Indice de tablas 47 Acr´onimos y siglas 49 II Cap´ıtulo 1 Introducci´on El protocolo RT-WMP [14] (Real-Time Wireless Multi-hop Protocol), desarrollado dentro del Grupo de Rob´otica, Percepci´on y Tiempo Real, es un protocolo de tiempo real con multitud de aplicaciones de distinta naturaleza. Su aplicaci´on m´as com´un es la de conectar a peque˜nos equipos de robots m´oviles (v´ease por ejemplo [6]) u ofrecer conexi´on de voz a nodos m´oviles en entornos complicados [9]. Sin embargo, las redes construidas con este protocolo se encuentran aisladas del mundo exterior. Esto implica que no es posible tener acceso a los nodos que la constituyen desde fuera ni acceder a redes externa (por ejemplo Internet) desde dentro de la red. Con este proyecto se intenta superar estas limitaciones, permitiendo el uso de aplicaciones convencionales sobre estas redes y su interconexi´on con redes basadas en IP. Adem´as, se permitir´a que las aplicaciones funcionando sobre redes RT-WMP hagan uso de sus caracter´ısticas, tales como la asignaci´on de prioridades est´aticas o la gesti´on de la calidad de servicio en las comunicaciones. 1.1 Contexto Este proyecto se ha desarrollado en el Laboratorio de Rob´otica del Instituto de Investigaci´on en Ingenier´ıa de Arag´on(I3A), dentro del Grupo de Rob´otica, Percepci´on y Tiempo Real del Departamento de Inform´atica e Ingenier´ıa de Sistemas (DIIS) y m´as concretamente en el marco del proyecto TESSEO (Sistemas Multi-Robot en Aplicaciones de Servicio y Seguridad - TEams of robots for Service and Security missiOns), que se encarga de la investigaci´on de t´ecnicas para que sistemas multi-robot act´uen coordinadamente en escenarios realistas. En este grupo, se emplea el protocolo RT-WMP para m´ultiples aplicaciones, algunas de las cuales son: •Desplegar grupos de robots en misiones de reconocimiento y rescate, permiti´endoles establecer una comunicaci´on en tiempo real entre ellos y mantener el contacto con el puesto de control. •Ofrecer cobertura en situaciones y lugares donde no se disponga de las redes de comunicaci´on convencionales, como puede ser el interior de un t´unel o de una cueva, por medio del despliegue de una serie de nodos comunicados por este protocolo. Algunos ejemplos de los trabajos realizados por este grupo son: Sistema multi-robot en localizaci´on e identificaci´on de veh´ıculos [6], Enforcing Network Connectivity in Robot Team Missions [13] y Real-Time Wireless Multi-Hop protocol in Underground Voice Communication [9], entre muchos otros. CAP´ ITULO 1. INTRODUCCI ´ ON 1.2. OBJETIVOS RT-WMP es un protocolo que soporta tr´afico de tiempo real estricto para redes m´oviles ad hoc (Mobile ad hoc network, MANET) y que funciona sobre dispositivos que utilizan el protocolo 802.11. Emplea un esquema de paso de testigo para garantizar tiempos l´ımite de transmisi´on y est´a completamente descentralizado. El protocolo soporta prioridad est´atica de mensajes y cambios frecuentes en la topolog´ıa de la red gracias al intercambio entre los nodos de una matriz de adyacencia con informaci´on de la calidad del enlace entre estos. Un ejemplo de respuesta a un cambio de la topolog´ıa puede observarse en la figura 1.1. Stable RT-WMP Link QoS Flow Unstable RT-WMP Link I) II) AB AB B B Figura 1.1: Cambio de nodo en funci´on de la calidad del enlace El protocolo RT-WMP se explicar´a en el siguiente apartado de esta memoria. 1.2 Objetivos Si bien el protocolo RT-WMP cumple con su objetivo, tambi´en tiene ciertas limitaciones que se desean superar. Estas limitaciones radican en el hecho de que una red comunicada por este protocolo se encuentra aislada del exterior y en que para las comunicaciones dentro de esta no pueden emplearse programas de comunicaci´on convencionales. Esto es debido a que estos est´an dise˜nados generalmente para comunicaciones empleando el protocolo de Internet (IP) y m´as espec´ıficamente TCP/IP, mientras que para las comunicaciones dentro de la red se deben emplear programas dise˜nados espec´ıficamente para funcionar sobre RT-WMP. En la configuraci´on disponible hasta el momento el RT-WMP es una liber´ıa que solo pueden usar procesos que se ejecutan es espacio de usuario, heredando todas las limitaciones que ello implica. Esto significa que los programas que quieran usar este protocolo de comunicaci´on deben dise˜narse espec´ıficamente para ello y emplear la interfaz que ofrece para llevar a cabo la comunicaci´on en s´ı. Debido a esto, los programas comerciales que acceden a la red de manera est´andar, como por ejemplo el Secure Shell (SSH), no pueden usar este tipo de red para comunicar con los distintos nodos que la constituyen. La figura 1.2 (izquierda y centro) ilustra las diferencia entre los tipos de comunicaci´on que se pueden llevar a cabo mediante el funcionamiento est´andar de un sistema operativo normal y las que, hasta este momento, permite RT-WMP. La figura 1.2 (derecha) muestra, sin embargo, el sistema que se quiere obtener con el desarrollo de este proyecto. La configuraci´on actual impone limitaciones importantes en algunas situaciones, como por ejemplo, aquellas en las que se quiere acceder remotamente a uno de los nodos con el cual no se tenga posibilidad de conexi´on directa. Los objetivos principales de este proyecto ser´an, por tanto, permitir la comunicaci´on de forma transparente de cualquier tipo de programa que se ejecute en espacio de usuario y que 2 CAP´ ITULO 1. INTRODUCCI ´ ON 1.2. OBJETIVOS Aplicación AppRT-WMP Sistema operativo Capa de red de Linux Aplicación wlan0 wlan0 wmp0 Hardware driver driver pasarela RT-WMP ath5k_raw Figura 1.2: Comunicaciones con y sin RT-WMP utilice el protocolo IP en la capa de red (en la pr´actica, casi la totalidad de las aplicaciones). Esto, adem´as, abre la puerta a la posibilidad de poner en comunicaci´on las redes RT-WMP con redes IP trav´es de una pasarela y garantizar, por ejemplo, el acceso a Internet de nodos que se encuentren a muchos saltos de distancia del nodo que ejecute la pasarela, como ilustra la figura 1.3. La soluci´on pasa por adaptar el protocolo al espacio de kernel y extender sus funcionalidades mediante una interfaz virtual adicional, que los programas puedan utilizar de forma transparente como cualquier otra. Nodo Nodo Nodo Nodo Nodo Firefox Internet Figura 1.3: Nodo accediendo a internet mediante otro nodo distante Adem´as, se quiere mantener la posibilidad de utilizar el protocolo RT-WMP como medio para establecer comunicaciones con requisito de tiempo real de la misma forma en la que se permit´ıan antes aprovechando, sin embargo, la mayor eficiencia que supone el hecho de ejecutar el n´ucleo del protocolo en espacio de kernel en vez de usuario. 1.2.1 Ejemplos de aplicaciones Una vez alcanzado este objetivo, podr´ıan emplearse programas convencionales de comunicaci´on en situaciones en las que se utilice RT-WMP para ofrecer cobertura, simplificando de esta manera las tareas de las personas que necesiten hacer uso de esta cobertura, como puede ser un equipo de emergencias. Otro tipo de situaciones donde este sistema podr´a resultar ´util es en el despliegue de grupos de robots, donde estos no siempre muestran el comportamiento esperado; en este tipo de situaciones ser´ıa muy interesante poder establecer una conexi´on con uno de los robots y estudiar la situaci´on o, si hiciera falta, reiniciar un proceso problem´atico. Este problema se solventa empleando la soluci´on presentada en este proyecto, dado que la conexi´on se establecer´a por medio de la red RT-WMP. 1.2.2 Otros objetivos Adem´as de los objetivos anteriores, se desea disponer de la posibilidad de emplear los mecanismos de asignaci´on de prioridades y de calidad de servicio de los que dispone RT-WMP 3 Cap´ıtulo 3 An´alisis y dise˜no del sistema En este cap´ıtulo se realiza una descripci´on de la soluci´on implementada, en primer lugar de forma general y despu´es de forma m´as detallada, as´ı como de los pasos seguidos a lo largo del proyecto. 3.1 An´alisis La divisi´on del sistema en m´odulos fue un paso directo, puesto que ya se dispon´ıa de una modificaci´on del driver ath5k y del protocolo RT-WMP implementado como una librer´ıa. El ´unico m´odulo completamente nuevo en el sistema es la propia pasarela. El m´etodo de implementaci´on de la pasarela, que fue un m´odulo del n´ucleo de Linux como se ver´a m´as adelante, vino impuesto por las funcionalidades que deb´ıa proveer, puesto que no existe ning´un otro modo de satisfactorio de lograrlas. En cuanto a la implementaci´on interna de la pasarela, esta necesita gestionar varios flujos para los diferentes tipos de tr´afico (broadcast, QoS, etc.). Por ello, en el env´ıo los paquetes ser´an diferenciados seg´un su tipo y se emplear´a la funci´on apropiada de RT-WMP y en la recepci´on se tendr´an hilos de ejecuci´on esperando la llegada de nuevos datos en cada uno de estos flujos. Las consideraciones de la fase de an´alisis sobre aspectos m´as concretos del sistema ser´an tratadas a lo largo de la descripci´on de la soluci´on, en las secciones posteriores de este cap´ıtulo. 3.2 Introducci´on a la soluci´on En la figura 3.1 pueden observarse las diferencias entre una situaci´on en la que un ordenador se comunica por medio de una red IP (izquierda) y como se comunica a trav´es de una red RT-WMP usando el sistema construido a lo largo de este proyecto (derecha). En la primera situaci´on, la capa de red de Linux decide a trav´es de que interfaz de red enviar los datos y esta, por medio del controlador de dispositivo, realiza el env´ıo de los datos con la tarjeta de red. En la recepci´on, el driver proporciona los datos a la capa de red y esta los entrega a la aplicaci´on que los espera o los descarta. En nuestro caso en cambio, los datos IP generados por las aplicaciones atraviesan la pasarela, esta los env´ıa al m´odulo RT-WMP y este a su vez los transmite por medio de ath5k raw. Sin embargo, para las aplicaciones no hay diferencia, estas solo ven una interfaz de red por la que env´ıan y reciben datos. CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.2. INTRODUCCI ´ ON A LA SOLUCI´ ON ath5k_raw RT-WMP Pasarela Linux Network Layer Hardware Aplicaciones Linux Network Layer Aplicaciones Hardware driver Sistema operativo Figura 3.1: Esquema general Adem´as de permitir la comunicaci´on IP por medio de redes RT-WMP, tambi´en se proporciona un mecanismo para la comunicaci´on directa por medio de RT-WMP. Todos estos aspectos ser´an descritos con mayor detalle en secciones posteriores de este cap´ıtulo. En lo que al sistema construido a lo largo de este proyecto se refiere, a simple vista puede observarse como ha sido a˜nadido un componente, la pasarela, que se ocupa de tomar el tr´afico IP generado localmente, encapsularlo dentro de mensajes RT-WMP y enviarlo al nodo correspondiente de la red, as´ı como de recibir por medio del protocolo el tr´afico IP encapsulado dentro de sus mensajes y envi´andolo posteriormente a la capa de red de Linux para que esta lo haga llegar a la aplicaci´on destino. Adem´as de a˜nadir la pasarela, ha sido necesario realizar modificaciones en el controlador ath5k raw y principalmente en RT-WMP, donde se ha a˜nadido una tercera plataforma que funciona en espacio de kernel como un m´odulo. Estas modificaciones ser´an descritas en las siguientes secciones junto con una explicaci´on pormenorizada de la pasarela. 3.2.1 Espacio de kernel Antes de continuar con la explicaci´on se va a realizar una breve explicaci´on de la arquitectura del propio n´ucleo de Linux, para poder entender con mayor facilidad la siguientes secciones. Linux divide la memoria del sistema en dos espacios completamente separados, conocidos como espacio de kernel (kernel space) y espacio de usuario (user space). El c´odigo que se ejecuta en el primero, el que forma parte del sistema operativo, tiene acceso ´ıntegro y sin restricciones al sistema, mientras que el c´odigo ejecutado en espacio de usuario, las aplicaciones, tiene que utilizar los mecanismos que les proporciona el sistema operativo para acceder a los recursos del sistema. Por otra parte, el n´ucleo de Linux es un n´ucleo monol´ıtico h´ıbrido, lo que significa que el c´odigo que tiene que ser ejecutado en espacio de kernel no necesita formar parte del n´ucleo. Esto significa que no hay que recompilarlo cada vez que se necesita a˜nadir funcionalidades o a˜nadir un nuevo controlador de dispositivo, sino que se proporciona un mecanismo por el cual estas funcionalidades pueden a˜nadirse mientras este se encuentra en ejecuci´on, en forma de m´odulos (Linux Loadable Kernel Module, LKM [7]). 12 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA 3.3 Descripci´on detallada 3.3.1 Visi´on global Para poder emplear programas dise˜nados para funcionar sobre IP en una red RT-WMP sin modificarlos es necesario que todo el sistema resulte transparente para estos. El modo empleado para lograr esto consisti´o en crear una interfaz de red virtual, que se comporta de la misma forma que cualquier otra interfaz ethernet desde el punto de vista de las aplicaciones, pero que internamente realiza las transmisiones por medio de RT-WMP. Como ya se ha comentado anteriormente, este es el papel de la pasarela. La pasarela necesita realizar operaciones que solo pueden realizarse desde espacio de kernel, como la creaci´on y configuraci´on de una interfaz de red, por lo que hubo que implementarla como un m´odulo del kernel de Linux. Lo mismo se hizo con RT-WMP, hecho que provoc´o gran parte de las numerosas modificaciones que se comentar´an posteriormente en este cap´ıtulo. 3.3.2 Modificaciones al controlador Para que RT-WMP pudiese obtener al ponerse en funcionamiento la interfaz de red controlada por ath5k raw a utilizar, se realizaron las modificaciones oportunas en este ´ultimo para que guardase la informaci´on de la primera interfaz de red registrada con dicho controlador y se implement´o un procedimiento que permite obtener dicha informaci´on. Por otro lado, se decidi´o realizar la comunicaci´on entre RT-WMP yath5k raw directamente, sin pasar por la capa de red de Linux, evitando as´ı el indeterminismo temporal que ello implicar´ıa (algo indeseable al tratarse de un protocolo de tiempo real) y acelerando las comunicaciones al haber reducido las operaciones intermedias. Las implicaciones que esta decisi´on tuvo en cuanto a la transmisi´on fueron m´ınimas, puesto que simplemente hubo que realizar el env´ıo de los datos desde RT-WMP directamente, invocando la funci´on de transmisi´on de la interfaz ath5k raw en lugar de enviarlos a la capa de red de Linux por medio de la funci´on correspondiente. Una representaci´on de esta situaci´on puede verse en la figura 3.2. RT-WMP ath5k_raw tx rx Linux Network Layer Figura 3.2: Comunicaci´on entre ath5k raw y RT-WMP Antes de modificarlo, el controlador trataban los datos provenientes de la red de la forma apropiada y los enviaba a la capa de red por medio de la funci´on definida en el n´ucleo de Linux a tal efecto. Una vez echo esto, el protocolo no ten´ıa necesidad de almacenar estos datos a la espera de que la aplicaci´on correspondiente los solicitase, la capa de red de Linux lo hac´ıa en su lugar. Sin embargo, para hacer llegar sus datos directamente al protocolo RT-WMP es necesario almacenarlos dentro del propio controlador a la espera de que el protocolo solicite su recepci´on por medio de una funci´on implementada con ese prop´osito 13 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA En primer lugar hubo que distinguir, dentro de ath5k raw, entre los paquetes pertenecientes al protocolo y el resto de paquetes, para de este modo seguir mandando a la capa de red aquellos ajenos RT-WMP, como se puede ver en la figura 3.2. Esto se consigui´o f´acilmente realizando una comparaci´on sobre el campo que contiene el protocolo de los paquetes dentro de la cabecera del protocolo ethernet. En segundo lugar, se implement´o un mecanismo para almacenar los paquetes a la espera de ser solicitados por el protocolo RT-WMP. Mediante este se garantiza el acceso en exclusi´on mutua a los datos, dado que pueden existir accesos concurrentes, y se permite bloquearse a la espera de la recepci´on de nuevos datos, algo requerido por las funciones empleadas por RT-WMP para solicitar estos datos. Con ello ya se dispon´ıa de todas las herramientas necesarias para realizar la comunicaci´on desde y hacia el protocolo RT-WMP sin pasar por la capa de red de Linux, directamente con ath5k raw. Por ´ultimo, RT-WMP utilizaba llamadas ioctl (ver m´as adelante) para configurar la interfaz ath5k raw de acuerdo a sus necesidades, pero la funci´on que atiende estas llamadas est´a dise˜nada para recibir los datos desde el espacio de usuario. La soluci´on a esta situaci´on pas´o por crear una nueva funci´on adaptando la anterior, de manera que permitiese realizar estas mismas configuraciones pero recibiendo los datos desde otro m´odulo, es decir, desde espacio de kernel. 3.3.3 Adaptaci´on de RT-WMP Como ya se ha comentado, las modificaciones en RT-WMP vinieron principalmente ocasionadas por la necesidad de que este pudiese funcionar como un m´odulo del kernel. Este entorno, de hecho, supone ciertas limitaciones y obliga a tener tener en cuenta factores que no se dan programando para espacio de usuario: •No se dispone de las bibliotecas est´andar de C. Gran parte de las funciones de las bibliotecas est´andares de C tienen su equivalente en el kernel, por lo que en estos casos los cambios se limitan al nombre, pero no siempre es as´ı. •Por defecto, la aritm´etica de coma flotante no est´a soportada. •Las divisiones con enteros de 64 bits no est´an soportadas de forma nativa en m´aquinas de 32 bits. •En el espacio de usuario, no liberar la memoria din´amica que se reserva es una mala pr´actica de programaci´on, puesto que se producen fugas de memoria hasta que el programa finaliza su ejecuci´on; es grave pero no es algo dram´atico por lo general, puesto que esta memoria es liberada una vez que el programa finaliza. Sin embargo, en espacio de kernel esto no sucede, puesto que la memoria asignada din´amicamente es memoria del kernel, no se guarda informaci´on de que m´odulo es el que la ha reservado, por lo que si el m´odulo no se encarga de liberarla, esa memoria permanecer´a marcada como ocupada hasta que se reinicie el sistema, una situaci´on potencialmente catastr´ofica. Por ello, hay que asegurarse de que toda la memoria din´amica reservada se libera posteriormente. Para solventar esta situaci´on y que el c´odigo siguiese siendo v´alido para las dos plataformas para las que estaba implementado RT-WMP, se a˜nadi´o una tercera. 14 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA Integraci´on de las plataformas La forma de hacer que el protocolo compilase y funcionase en dos sistemas diferentes era teniendo gran parte del c´odigo com´un para ambas y disponer de un directorio para cada plataforma con el c´odigo espec´ıfico para cada una de ellas, de forma que era en el momento de la compilaci´on cuando se decid´ıa utilizar los ficheros para la plataforma requerida, por medio de los mecanismos de compilaci´on condicional que provee el conjunto de herramientas del proyecto GNU (autotools). Interfaz Core linux_us MaRTE_OS sockets raw ... Figura 3.3: Ejemplo del sistema compilado En la figura 3.3 puede observarse una situaci´on en la que el protocolo se encuentra compilado para la plataforma linux us. Esta forma de trabajar tiene la ventaja de que la mayor parte del c´odigo a las diferentes plataformas es com´un, no hay que mantener versiones diferentes del protocolo. Adem´as, si se descubre un fallo en la implementaci´on del CORE solo habr´a que solucionarlo una vez, en lugar de tener que solucionarlo en cada una de las versiones. Para las funciones que son diferentes entre las plataformas, cada una de ellas dispone de un fichero en el que se se encuentran definidos los mismos macros del preprocesador de C, pero en cada uno de ellos se definen como llamadas a las funciones correspondientes a la plataforma. De esta forma, en el c´odigo en com´un se emplean los macros y a la hora de la compilaci´on el preprocesador se encarga de sustituirlos por las llamadas a funci´on correspondientes. Este mecanismo fue especialmente ´util para solventar el primero de los problemas se˜nalados. Se definieron para la nueva plataforma los macros que ya exist´ıan para las anteriores y se a˜nadieron a las tres aquellos que fueron necesarios por la inclusi´on de la tercera, sustituyendo en el c´odigo en com´un las antiguas llamadas a funci´on por estos nuevos macros. #de f in e MALLOC( s i z e ) malloc ( s i z e ) /∗En l i n u x u s y MaRTE OS ∗/ #de f in e MALLOC( s i z e ) kmalloc ( si ze , GFP KERNEL) /∗En linux ks ∗/ /∗Ejemplo de uso d e l macro ∗/ d=(long ∗) MALLOC(n∗sizeof(long )); Figura 3.4: Diferentes definiciones de un macro y ejemplo de su uso Un ejemplo de lo anteriormente se˜nalado es la reserva de memoria din´amica. Tanto en MaRTE OS como en Linux en el espacio de usuario se emplea la funci´on malloc, pero esta funci´on no est´a disponible en el espacio de kernel, sino que existe una similar llamada kmalloc. La soluci´on a este problema fue a˜nadir un macro con la funci´on correspondiente en cada plataforma, como puede observarse en el ejemplo de la figura 3.4. 15 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA En las pocas ocasiones en las que no exist´ıan funciones similares que pudiesen ser empleadas, estas se implementaron completamente. Tal fue el caso de la funci´on fgets, de la que se hablar´a m´as adelante, entre otras. Un ejemplo de implementaci´on de la funci´on atoi por medio de un macro puede verse en la figura 3.5. #d e f i n e a t o i ( s ) \ ({ \ char ∗next ; \ (int) s i m p l e s t r t o l ( s ,&next , 1 0 ) ; \ }) Figura 3.5: Implementaci´on de una funci´on inexistente en el kernel Coma flotante Como se ha adelantado, las operaciones de coma flotante no est´an soportadas por defecto en espacio de kernel, esto es debido a una decisi´on de dise˜no del propio kernel. Se consider´o que en este espacio la aritm´etica flotante era completamente innecesaria excepto en casos muy excepcionales, adem´as de que guardar el contexto de la unidad de coma flotante (Floating-point unit, FPU) ocasionar´ıa que los cambios de contexto fuesen considerablemente m´as lentos, por lo que se decidi´o no guardar el contexto de la FPU autom´aticamente. Sin embargo, se proporcionan dos funciones por medio de las cuales se puede realizar esta operaci´on manualmente en caso de necesitarlo. Estas funciones son kernel fpu begin() ykernel fpu end(), entre las que debe situarse el c´odigo que implique operaciones de coma flotante. Para introducirlas en el c´odigo se definieron los macros FLOAT OPS START() yFLOAT OPS END(), que ser´an sustituidos por el preprocesador para el caso de linux ks por las funciones anteriores o simplemente eliminados para las otras dos plataformas. De esta forma, se minimiz´o el uso de las operaciones de coma flotante en la medida de lo posible, sustituy´endolas por operaciones con n´umeros enteros en las situaciones en las que este cambio era posible o reordenando el c´odigo para minimizar el numero de operaciones en otros casos. Una vez hecho esto, simplemente se emplearon los macros descritos anteriormente para envolver todos los fragmentos de c´odigo con operaciones de este tipo restantes en el c´odigo fuente del protocolo. Divisiones de 64 bits Como ya se ha comentado anteriormente, las divisiones de enteros de de 64 bits no est´an soportadas en el kernel en las arquitecturas en las que no existe un soporte hardware para ello. Sin embargo, se dispone de un macro definido en el n´ucleo de Linux (do div) que nos permite calcular simult´aneamente la divisi´on y el resto resultante entre dos n´umeros. A consecuencia de ello, hubo que localizar en el c´odigo del protocolo todas las operaciones de divisi´on que involucraban a los tipos long long yunsigned long long y sustituirlas por el macro DO DIV64. Este macro se defini´o en el fichero se˜nalado anteriormente, de forma que para las dos plataformas iniciales las divisiones se siguiesen realizando del mismo modo, pero que al compilar RT-WMP como m´odulo se emplease do div para el c´alculo. 16 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA Memoria din´amica La responsabilidad de liberaci´on de la memoria din´amica cuando se trabaja en espacio de kernel recae enteramente en el programador puesto que, como ya se ha comentado, ´esta no se libera autom´aticamente en ning´un momento. No liberar esta memoria supondr´ıa provocar fugas de memoria, dado que permanecer´ıa marcada como ocupada hasta un reinicio del sistema aunque realmente no lo est´a, una situaci´on potencialmente catastr´ofica. Por lo tanto, se procedi´o a localizar en el c´odigo fuente todas las reservas de memoria y a asegurarse de que ´esta fuese liberada en el momento oportuno. Ficheros de configuraci´on El protocolo RT-WMP cuenta con dos ficheros de configuraci´on, uno con opciones relativas a la configuraci´on del propio protocolo y otro con opciones para la configuraci´on de la tarjeta inal´ambrica. Sin embargo, como ya se ha comentado anteriormente, al trabajar en el espacio de kernel no disponemos de las funciones convencionales de manipulaci´on de ficheros. Aun as´ı, el kernel dispone de sus propias funciones, pese a no ser tan sofisticadas como las proporcionadas por las bibliotecas de C. Adem´as, el c´odigo encargado del tratamiento de los ficheros de configuraci´on no es com´un, sino que es espec´ıfico para cada plataforma, hecho que facilit´o la creaci´on de las funciones correspondientes a la nueva plataforma. Como las operaciones relacionadas con la lectura de datos eran considerablemente rudimentarias, se implement´o con ellas un equivalente a la funci´on fgets disponible en espacio de usuario. De esta forma se pudo reutilizar buena parte del c´odigo empleado en espacio de usuario para la lectura de los ficheros de configuraci´on, contando con la ventaja de que este c´odigo llevaba tiempo siendo utilizado, por lo que la probabilidad de que contuviese un error era menor. Los ficheros de configuraci´on en el espacio de usuario se sit´uan en un directorio dentro del HOME del usuario, pero al trabajar en el espacio de usuario se decidi´o situarlos en un lugar m´as apropiado para tal situaci´on, como es el directorio /etc. Por tanto, los ficheros de configuraci´on para el protocolo cuando este se compila como un m´odulo se encuentran en /etc/rt-wmp/. Extensiones Hasta ahora se ha hablado de las modificaciones realizadas a la implementaci´on del protocolo pero, como ya se ha comentado anteriormente, el protocolo cuenta con una serie de extensiones. Las cuatro extensiones explicadas en el cap´ıtulo anterior (multi queue,QoS,broadcast yfake lqm) sufrieron el mismo tipo de modificaciones que el resto del c´odigo, con el objetivo de poder hacer uso de ellas cuando el protocolo fuese compilado como un m´odulo del kernel. Adem´as, el sistema de extensiones de RT-WMP estaba dise˜nado para que al cargar una extensi´on se reservase la memoria necesaria para sus estructuras y se definiesen las funciones que se deb´ıan invocar en determinados momentos durante la ejecuci´on del protocolo. Sin embargo, no recib´ıan un aviso cuando el protocolo finalizaba, por lo que no ten´ıan forma de liberar su memoria. Para solucionarlo se a˜nadi´o al sistema de extensiones la posibilidad de definir una funci´on que se invoca en el momento de la detenci´on de protocolo, mediante la que estas pueden liberar la memoria reservada durante su carga para evitar fugas de memoria o deshacer cualquier otra operaci´on que necesite ser deshecha. 17 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA 3.3.4 Pasarela La pasarela es el m´odulo que se encarga de permitir las conexiones IP de forma transparente sobre redes construidas con el protocolo RT-WMP y, como ya se ha indicado anteriormente, esto lo consigue creando una interfaz de red virtual que lo enmascara. Función transmisión Cola normal Cola QoS Cola normal Cola QoS rx_thread rx_QoS_thread flow control Linux Network Layer Figura 3.6: Esquema general de la interfaz creada por la pasarela En la figura 3.6 pueden observarse los componentes principales de la interfaz que crea la pasarela: la funci´on de transmisi´on, que distingue seg´un el tipo de tr´afico, y los diferentes hilos de ejecuci´on. Las colas representadas en la figura son diferentes colas de transmisi´on y de recepci´on de RT-WMP. Al cargar el m´odulo de la pasarela se crea y registra esta interfaz en el sistema y se realizan las configuraciones oportunas, como puede ser la longitud de su cola de transmisi´on o su unidad m´axima de transferencia (Maximum Transfer Unit, MTU). Todos estos componentes ser´an descritos en los siguientes apartados. Puesta en funcionamiento A la hora de poner en funcionamiento la interfaz de la pasarela, se le asignar´a una direcci´on IP acorde a la subred de las m´aquinas conectadas a la red RT-WMP, de modo que pueda realizarse la comunicaci´on IP. Para simplificar la puesta en funcionamiento del sistema, se decidi´o emplear esta direcci´on para configurar el n´umero de nodos de la red y el identificador de nodo al lanzar el protocolo RT-WMP. Teniendo en cuenta que una direcci´on IP (versi´on 4) est´a compuesta por 4 bytes, se ignoran los dos bytes m´as significativos, el tercero se tomar´a como el n´umero de nodos de la red y el cuarto se usar´a para el identificador del nodo (teniendo en cuenta que las direcciones IP para m´aquinas comienzan en 1 y los identificadores de RT-WMP comienzan en 0). La figura 3.7 muestra una representaci´on gr´afica de la correspondencia entre IP yRT-WMP. Nº Nodos ID Nodo + 1 Byte 0 Byte 1 Byte 2Byte 3 Figura 3.7: Direcci´on IP / Datos de nodo RT-WMP De esta forma, si en una m´aquina se configura la interfaz virtual con la direcci´on IP 192.168.3.1 significar´a que la red RT-WMP est´a compuesta por tres nodos (incluida la propia m´aquina) y que la m´aquina tendr´a el identificador 0 en esa red. Por tanto, la funci´on invocada al poner en funcionamiento la interfaz se encarga de: •Generar aleatoriamente la direcci´on f´ısica de la interfaz. 18 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.3. DESCRIPCI´ ON DETALLADA •Obtener el n´umero de nodos de la red RT-WMP y el identificador de nodo de la m´aquina en funci´on de la direcci´on IP asignada a la interfaz e inicializar RT-WMP con ambos datos. •Cargar las extensiones necesarias del protocolo. •Leer el fichero de configuraci´on con la informaci´on de las prioridades para los diferentes tipos de tr´afico (ver m´as adelante). •Poner en funcionamiento RT-WMP y todos los hilos de ejecuci´on necesarios •Inicializar la cola de transmisi´on para poder empezar a usar la interfaz. Al detener la interfaz se invoca una funci´on que se ocupa de ordenar detenerse a todos los hilos, detener la cola de transmisi´on y finalizar RT-WMP, es decir, se ocupa de deshacer las operaciones realizadas por la funci´on de carga que necesitan ser deshechas. Transmisi´on La funci´on encargada de la transmisi´on de datos es uno de los elementos m´as importantes de la pasarela, puesto que es la que se encarga de enviar los datos IP encapsulados dentro de RT-WMP, la funci´on principal de la pasarela. La primera tarea de esta funci´on es asegurarse de que los datos a ser enviados pertenecen al protocolo IP, en otro caso se descartan. Una vez se sabe que el paquete a ser enviado es un paquete IP, se procede a obtener su destinatario dentro de la red RT-WMP por medio de su IP destino. En este paso pueden darse tres casos distintos en esta situaci´on: •La direcci´on pertenece a otra red, por lo que el paquete ser´a enviado al nodo n´umero 0, que hace de pasarela entre la red RT-WMP y el mundo exterior. •La direcci´on IP pertenece a la red local pero el identificador de nodo obtenido a partir de dicha IP no pertenece a ning´un nodo de la red (se sale de rango). En este caso se descarta el paquete. •La direcci´on pertenece a la red y el identificador de nodo es v´alido, por lo que el paquete ser´a enviado a dicho nodo. En la pasarela se ha creado una correspondencia directa entre direcciones IP locales e identificadores RT-WMP, pero cuando los env´ıos son al exterior de la red ´esta no sirve. La IP destino de tal env´ıo ser´a una externa a la red y la LNL utilizar´a el protocolo de resoluci´on de direcciones [5] (Address Resolution Protocol, ARP) para obtener la direcci´on f´ısica de la m´aquina que hace de pasarela de la red con el exterior. Una forma de solucionar este problema hubiese sido implementar una especie de ARP con el que se obtuviesen identificadores RT-WMP a partir de direcciones f´ısicas, mediante el que se hubiese podido obtener el nodo destino del paquete mediante su direcci´on f´ısica de destino, pero esto hubiese hecho los env´ıos m´as lentos y hubiese a˜nadido carga a la red, adem´as de la complejidad de la propia soluci´on. Por esta raz´on, se tom´o la decisi´on de fijar el nodo 0 como nodo que hace de pasarela de la red RT-WMP con el exterior y dejar para un posible trabajo futuro la posibilidad de a˜nadir la opci´on de configurar este nodo manualmente o implementar alg´un mecanismo como el que acaba de ser descrito. 19 CAP´ ITULO 3. AN´ ALISIS Y DISE˜ NO DEL SISTEMA 3.4. DESARROLLO DEL PROYECTO dos m´odulos separados pero la compilaci´on se realizase conjuntamente. Para ello, se integraron ambas compilaciones y se a˜nadi´o una opci´on al fichero de configuraci´on de la compilaci´on que permitiese decidir si se quiere compilar solo RT-WMP o tambi´en la pasarela. Adem´as, se tom´o la decisi´on de permitir la ejecuci´on del m´odulo de RT-WMP de forma aut´onoma, sin la pasarela encima, algo que hasta el momento no era posible puesto que era la propia pasarela quien configuraba y pon´ıa en funcionamiento el m´odulo. Para ello, se a˜nadieron una serie de par´ametros al m´odulo de RT-WMP que permiten seleccionar su funcionamiento en modo aut´onomo y configurarlo del mismo modo que lo har´ıa la pasarela. Este funcionamiento aut´onomo resulta interesante para nodos intermedios de la red, donde no hay interacci´on con el protocolo, sino que estos simplemente se encargan de transmitir el tr´afico de unos nodos hacia otros; en tales casos la pasarela resulta innecesaria. Una vez hecho esto, con el objetivo de facilitar el proceso de compilaci´on y puesta en funcionamiento del sistema, se procedi´o a integrar tambi´en la compilaci´on y la instalaci´on de ath5k raw con los otros dos m´odulos, para poder compilar e instalar los tres m´odulos conjuntamente. Para m´as detalles sobre como configurar y poner en funcionamiento el sistema, cons´ultese el ap´endice A. 26 Cap´ıtulo 4 Evaluaci´on y experimentos Con el objetivo de evaluar el rendimiento de la implementaci´on realizada a lo largo de este proyecto, as´ı como de realizar una comparaci´on entre la implementaci´on del protocolo en espacio de kernel y la de espacio de usuario, se realizaron una serie de pruebas en el laboratorio y una prueba final en el interior del antiguo t´unel ferroviario de Somport. 4.1 Entorno de pruebas Todas las pruebas se realizaron empleando: •El sistema desarrollado a lo largo de este proyecto funcionando en dos ordenadores personales. En una ocasiones la comunicaci´on se realizaba entre ambos y en otras uno de ellos hac´ıa de pasarela hacia internet. •Una serie de nodos de comunicaci´on desarrollados en un PFC anterior, ejecutando el protocolo RT-WMP sobre MaRTE OS conformando la estructura de la red por la que circulan los datos entre ambos ordenadores. 4.2 Pruebas en el laboratorio En las pruebas en el laboratorio todos los elementos conectados a la red RT-WMP se encontraban muy cercanos, por lo que la red resultaba completamente conexa. Para obligar a que el tr´afico entre ambos ordenadores circulase por medio de los nodos en esta situaci´on se emple´o la extensi´on fake lqm, de forma que cada nodo interpretase que solo pod´ıa establecer comunicaci´on con el nodo inmediatamente anterior a ´el y con el inmediatamente posterior, es decir, simulando una disposici´on lineal de acuerdo a su identificador. Por tanto, en todas las pruebas uno de los ordenadores ten´ıa el identificador 0 y el otro el m´aximo identificador de la red. Asimismo, durante las pruebas se ha empleado el programa wmpSniffer [12], que permite monitorizar comunicaciones RT-WMP para su posterior an´alisis. Para consultar los resultados num´ericos de las pruebas cons´ultese el ap´endice C. 4.2.1 Comparativa entre linux us y linux ks La primera de las pruebas consisti´o en la medici´on, con ayuda de wmpSniffer, del ancho de banda de la red para redes de diferente n´umero de nodos, desde 2 (los dos ordenadores) hasta CAP´ ITULO 4. EVALUACI´ ON Y EXPERIMENTOS 4.2. PRUEBAS EN EL LABORATORIO 7 (los ordenadores junto a los 5 nodos con MaRTE OS). Tanto en los ordenadores como en los nodos se lanz´o un programa que generaba tr´afico RT-WMP con destino y prioridad aleatorios, de forma que la red se encontrase saturada en el momento de realizar las mediciones. El objetivo de esta prueba era comparar las prestaciones de ambas implementaciones. En la figura 4.1 puede verse una gr´afica con los resultados de la prueba, donde se muestra para cada plataforma el ancho de banda obtenido para los diferentes tama˜nos de la red. Figura 4.1: Ancho de banda en redes de diferente tama˜no Como puede observarse, se ha conseguido una ganancia notable en el ancho de banda, aunque esta disminuye conforme crece el tama˜no de la red, alcanz´andose una ganancia de un 5 % aproximadamente con el m´aximo tama˜no. El hecho de las l´ıneas converjan es l´ogico, puesto que conforme el tama˜no de la red crec´ıa los nodos que se a˜nadidos funcionaban con MaRTE OS, por lo que ambos escenarios se iban pareciendo m´as. Duraci´on de una iteraci´on en el caso peor Con los resultados de esta prueba pudo analizarse tambi´en la duraci´on de una iteraci´on, es decir, el tiempo transcurrido desde que comienza una fase de arbitraje de prioridad hasta que comienza la siguiente, en el caso peor. Este tiempo ya ha sido estudiado anteriormente y puede representarse con la siguiente f´ormula: (2N−3)tt+(N−1)ta+(N−1)tm, siendo Nel n´umero de nodos de la red, ttel tiempo de transmisi´on de un token entre dos nodos, tael tiempo de transmisi´on de una autorizaci´on y tmel tiempo de transmisi´on de un mensaje de m´aximo tama˜no. Figura 4.2: Duraci´on de una iteraci´on en el caso peor 28 CAP´ ITULO 4. EVALUACI´ ON Y EXPERIMENTOS 4.2. PRUEBAS EN EL LABORATORIO En la figura 4.2 pueden observarse los resultados obtenidos para la plataforma linux ks con diferentes tama˜nos de la red. Como puede verse, los tiempos crecen linealmente con el tama˜no de la red, lo que concuerda con la formula te´orica. 4.2.2 Equidad (Fairness) En una segunda prueba, se configuraron todos los nodos de la red para emitir tr´afico con la misma prioridad y poder observar as´ı los retrasos en la entrega de los mensajes por medio de wmpSniffer. Figura 4.3: Retraso en la entrega de los mensajes El la figura 4.3 se representan los mensajes agrupados por su retraso en la entrega, es decir, el tiempo que transcurren circulando por la red desde el origen hasta el destino. Como puede verse, los mensajes tienden a tener todos el mismo retraso en la entrega, lo que es de esperar puesto que todos ellos tienen la misma prioridad. Figura 4.4: Retraso en la entrega de los mensajes + Arbitraje En la figura 4.4 es similar a la anterior, pero se ha a˜nadido el tiempo debido a la fase de arbitraje de prioridad, de forma que en esta gr´afica los mensajes se agrupan seg´un el tiempo desde que comienza el ciclo en el que van a ser enviados hasta que han alcanzado su destino. Al igual que en el caso de anterior, puede observarse como estos tiempos tienden a ser similares, debido una vez m´as a que todos los mensajes tienen la misma prioridad. 29 CAP´ ITULO 4. EVALUACI´ ON Y EXPERIMENTOS 4.3. PRUEBA DE CAMPO 4.2.3 Pruebas con Skype En esta prueba se configur´o uno de los ordenadores como pasarela a Internet, conect´andolo por cable a la red cableada, y con el otro ordenador se realizaron llamadas de voz mediante Skype, incrementando sucesivamente el tama˜no de la red. Pese a que el ancho de banda fue disminuyendo conforme aumentaba el tama˜no de la red, como era de esperar, las comunicaciones pudieron mantenerse sin ning´un tipo de problema. 4.2.4 Prueba completa La ´ultima prueba realizada en el laboratorio se efectu´o con el objetivo de comprobar el correcto funcionamiento de todos los elementos con la configuraci´on que tendr´ıan en la prueba de campo. Por tanto, la m´aquina que hizo de pasarela a Internet se conect´o por medio de un tel´efono m´ovil con 3G y se configuraron 4 nodos con MaRTE OS a la frecuencia adecuada. 4.3 Prueba de campo Como ya se ha comentado anteriormente, la prueba de campo se efectu´o en el t´unel de Somport, cuya secci´on puede verse en la figura 4.5, un antiguo t´unel ferroviario situado en la frontera entre Espa˜na y Francia. Figura 4.5: Secci´on del t´unel de Somport 4.3.1 Preparaci´on En primer lugar, se situ´o un un ordenador port´atil conectado a internet por medio de un tel´efono m´ovil con 3G en la boca del t´unel (figura 4.6) y se configur´o para que fuese el nodo 0 de la red RT-WMP, es decir, la pasarela al exterior. El objetivo de esta prueba era demostrar la posibilidad de ofrecer cobertura de voz en el t´unel por medio del sistema implementado durante el proyecto, usando aplicaciones convencionales para la comunicaci´on. A continuaci´on, se situ´o el primero de los nodos con MaRTE OS (figura 4.6) a un kil´ometro de la boca y se situaron los otros 3 nodos de forma que entre cada par consecutivo de nodos hubiese buena se˜nal. De esta forma las distancias entre los nodos fueron de algo m´as de un kil´ometro. Una vez configurados los elementos est´aticos de la red, se configur´o un segundo ordenador port´atil para que se conectase a la red RT-WMP, con lo que la red de 6 nodos estaba completa. 4.3.2 Pruebas Tras asegurarse de que la conexi´on a internet en el segundo port´atil por medio de la red RT-WMP funcionaba correctamente se procedi´o a efectuar las pruebas. 30 CAP´ ITULO 4. EVALUACI´ ON Y EXPERIMENTOS 4.3. PRUEBA DE CAMPO Figura 4.6: Port´atil que hace de pasarela y nodo intermedio Primera prueba En la primera de las pruebas se mantuvo una conversaci´on por medio del chat de voz de Gmail mientras se circulaba en con un coche desde la boca del t´unel hasta varios kil´ometros en su interior, de forma que el port´atil tuviese que cambiar sucesivamente de nodo con el que manten´ıa la comunicaci´on para estar conectado a la red. Pese a que la comunicaci´on de voz no fue perfecta, en especial cuando se estaba situado en una zona entre dos nodos, la conexi´on no se vio interrumpida y pudo mantenerse una comunicaci´on bastante fluida pese a estar viajando por el t´unel en el interior de un coche y a estarse realizando la comunicaci´on por medio de una red 3G. Segunda prueba En la segunda de las pruebas se mantuvieron dos conversaciones con dos personas diferentes (una en Zaragoza y otra en Alemania); en esta ocasi´on en el exterior del veh´ıculo. En esta prueba la comunicaci´on se pudo realizar sin ning´un problema y ambas partes de la comunicaci´on escuchaban a la otra claramente y sin interrupciones de ning´un tipo. ´ Ultima prueba En la ´ultima de las pruebas se emple´o el programa de VoIP Skype para realizar la comunicaci´on, por realizar una prueba con un programa diferente. Los resultados de esta prueba fueron similares a los de la anterior, la comunicaci´on se mantuvo con fluidez 31 Cap´ıtulo 5 Conclusiones y trabajo futuro 5.1 Conclusiones Los objetivos de este proyecto eran, por un lado, permitir el uso de aplicaciones convencionales sobre redes RT-WMP y su interconexi´on con redes IP y, por otro, permitir que estas aplicaciones hagan uso de caracter´ısticas de RT-WMP tales como la asignaci´on de prioridades est´aticas o la gesti´on de la calidad de servicio en las comunicaciones. Durante la realizaci´on de este proyecto se han ido cumpliendo satisfactoriamente todos estos objetivos. Por un lado, se ha completado la implementaci´on de la pasarela entre ambos protocolos, permitiendo de esta forma establecer comunicaciones IP sobre redes RT-WMP. El disponer de esta herramienta facilitar´a la realizaci´on de ciertas aplicaciones del grupo, puesto que se podr´a acceder remotamente a equipos que est´en comunic´andose mediante RT-WMP sin interferir en su comunicaci´on, como pueden ser grupos de robots desplegados en alg´un escenario. Adem´as, si la red se conecta a internet por medio de uno de los nodos, como se ha hecho en varias de las pruebas realizadas durante este proyecto, se podr´a interactuar con ellos o verificar su correcto funcionamiento sin necesidad de desplazarse hasta su posici´on, tanto desde el puesto de mando de la propia aplicaci´on como desde cualquier otra posici´on, a trav´es de internet. Por otro, se ha dotado a la pasarela de la posibilidad de emplear los mecanismos de prioridades est´aticas y de calidad de servicio de los que dispone el protocolo, cumpliendo el ´ultimo de los objetivos del proyecto. Mediante este mecanismo se pueden priorizar los tr´aficos importantes y evitar que otros menos importantes saturen la red. Adem´as de la consecuci´on de los objetivos del proyecto, se han implementado algunas funcionalidades adicionales que se consideraron ´utiles para el sistema, como puede ser la creaci´on de ficheros en el directorio /proc mediante los que consultar el estado del sistema y poder modificar ciertas opciones del protocolo. Asimismo, se implement´o el mecanismo de acceso a RT-WMP mediante ioctl y la biblioteca para las aplicaciones, de forma que la consecuciones de los objetivos del proyecto no supusiese la p´erdida de funcionalidades del sistema. Por ´ultimo, se valid´o el correcto funcionamiento del sistema desarrollado mediante de pruebas en un escenario real, verificando que todos los elementos del sistema funcionaban correctamente. En un ´ambito m´as personal, mi valoraci´on del proyecto es muy positiva puesto que, adem´as de alcanzarse con ´exito los objetivos del proyecto, me ha permitido adquirir una valiosa experiencia trabajando con m´odulos del n´ucleo de Linux y con manejadores de dispositivo, as´ı como con CAP´ ITULO 5. CONCLUSIONES Y TRABAJO FUTURO 5.2. TRABAJO FUTURO ciertos aspectos de las redes de comunicaci´on. Adem´as, me ha permitido colaborar en un proyecto de software libre como es el protocolo RT-WMP. 5.2 Trabajo futuro Aunque los objetivos del proyecto se han cumplido con ´exito, existen funcionalidades que pueden ser a˜nadidas al sistema y aspectos en los que se puede trabajar. Un posible trabajo futuro del que ya se ha hablado durante la memoria es la posibilidad de modificar la implementaci´on del acceso a RT-WMP por medio de icmp para las aplicaciones, realiz´andolo por medio de otro tipo de sockets que evitar´ıan el encapsulado de las recepciones en paquetes UDP, aunque requerir´ıan ejecutar los programas con privilegios de administrador. Otro aspecto en el que se puede trabajar es en la configuraci´on del nodo que hace de pasarela al exterior. Actualmente dicho nodo tiene que ser configurado con el identificador n´umero 0 de RT-WMP, pero podr´ıa estudiarse el hacer dicha configuraci´on m´as flexible. En lo referente a las extensiones, existen varios aspectos en los que se puede trabajar. Por un lado, la extensi´on multi queue es empleada en la actualidad por la pasarela para crear colas adicionales para su comunicaci´on y no se le da posibilidad al usuario de crear las suyas propias. Por lo tanto, el trabajo consistir´ıa en dar dicha posibilidad al usuario. Por otro, durante la realizaci´on de este proyecto se han adaptado las extensiones necesarias para ser empleadas con la plataforma linux ks, pero RT-WMP cuenta con otras extensiones que tambi´en pueden ser adaptadas. Un posible trabajo a m´as largo plazo consistir´ıa en a˜nadir m´as versiones de la capa de bajo nivel del protocolo, con el objetivo de soportar m´as tipos de tarjetas, como pueden ser las Atheros m´as modernas, que emplean el driver ath9k en lugar del ath5k. Por ´ultimo, alej´andose ya de temas directamente relacionados con la implementaci´on, existe la posibilidad de realizar una publicaci´on con el trabajo realizado a lo largo de este proyecto. 34 Ap´endice A Manual de uso En este ap´endice se tratan los aspectos relacionados con la compilaci´on, configuraci´on y puesta en funcionamiento de los tres m´odulos que componen el sistema. El sistema operativo necesario para compilar y ejecutar los tres m´odulos es GNU/Linux, con un kernel de Linux razonablemente moderno. Adem´as, para la compilaci´on es necesario tener instalados en el sistema las cabeceras del kernel (paquete linux-headers o similar) y los programas autoconf,automake,make ygcc. A.1 Compilaci´on e instalaci´on Pese a que el sistema completo est´a compuesto por tres m´odulos, el m´etodo de compilaci´on e instalaci´on ha sido dise˜nado para que todo se haga conjuntamente, evitando as´ı complicaciones al usuario. Los comandos que se describen a continuaci´on presuponen que se est´a situado en el directorio principal del protocolo y que se dispone de las herramientas necesarias para realizar las siguientes operaciones. A.1.1 Previos En primer lugar, se actualizan los ficheros de configuraci´on necesarios por medio del comando autoreconf y se generan todos los ficheros Makefile.in a partir de los correspondientes Makefile.am, por medio del comando automake -a, instalando en el proceso los ficheros est´andar que falten: $ autoreconf $ automake -a Una vez hecho esto, est´a todo listo para proceder a la configuraci´on de la compilaci´on. A.1.2 Configuraci´on En este paso se indica que debe compilarse RT-WMP para la plataforma linux ks, dado que no es la plataforma por defecto. $ ./configure --with-platform=linux_ks Adem´as, en caso de querer compilar solo ath5k raw yRT-WMP y no la pasarela, se debe proporcionar el par´ametro –disable-ip-interface. AP´ ENDICE C. RESULTADOS DE LAS PRUEBAS C.2. DURACI ´ ON DE UNA ITERACI´ ON C.2 Duraci´on de una iteraci´on En esta prueba se estudi´o la duraci´on de una iteraci´on (tiempo entre el comienzo de una PAP hasta la siguiente) en el caso peor para la plataforma linux ks. En la tabla C.2 se muestran de los resultados de las medidas obtenidas con wmpSniffer para la duraci´on de este intervalo en redes de diferente tama˜no. Si todos los nodos ejecutasen sistemas operativos de tiempo real, la duraci´on en el caso peor deber´ıa ser siempre la misma para redes del mismo tama˜no, la calculada mediante la f´ormula (2N−3)tt+ (N−1)ta+ (N−1)tm, siendo Nel n´umero de nodos de la red, ttel tiempo de transmisi´on de un token entre dos nodos, ta el tiempo de transmisi´on de una autorizaci´on y tmel tiempo de transmisi´on de un mensaje de m´aximo tama˜no. Sin embargo, Linux no lo es un sistema operativo de tiempo real, por lo que introduce indeterminismo temporal. Debido a ello, se muestra para cada tama˜no el m´aximo y el m´ınimo tiempo medido para situaciones de caso peor, adem´as de la media. WC LOOP Duration 2 Media M´aximo M´ınimo 2 2171 9678 1812 3 4909 14636 4414 4 8558 14467 7567 5 12163 18552 10834 6 14494 15465 14227 7 18722 18734 18711 Tabla C.2: Duraci´on del intervalo en el caso peor. En la figura C.2 puede observarse la representaci´on gr´afica de la media para la duraci´on de un intervalo en el caso peor de los diferentes tama˜nos de la red. Figura C.2: Duraci´on de una iteraci´on en el caso peor C.3 Resto de pruebas Dado que los aspectos relacionados con el resto de pruebas realizadas ya han sido tratados en el cap´ıtulo 4, no volver´an a repetirse en el presente ap´endice. 42 Bibliograf´ıa [1] Documentation extracted from the Linux kernel and mirrored on the web :: Kbuid. http://www.kernel.org/doc/Documentation/kbuild/modules.txt. [2] MaRTE OS Home Page. http://marte.unican.es/. [3] J. Corbet, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers, 3rd Edition. O’Reilly Media, Feb. 2005. [4] B. Nguyen. Linux Documentation Project - Linux Filesystem Hierarchy: 1.14. /proc. http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html. [5] D. C. Plummer. An Ethernet Address Resolution Protocol. Network Working Group - Request For Comments, 826, November 1982. [6] C. Sagues, A. Mosteo, D. Tardioli, J. Villarroel, L. Montano, and L. Montano. Sistema multi-robot en localizaci´on e identificaci´on de veh´ıculos. Revista Iberoamericana de Autom´atica e Inform´atica, 2011. [7] P. J. Salzman, M. Burian, and O. Pomerantz. The Linux Kernel Module Programming Guide. http://tldp.org/LDP/lkmpg/2.6/html/. [8] E. Schrock. Reflections on OS integration: A brief history of /proc. http://blogs.oracle.com/eschrock/entry/the power of proc/, June 2004. [9] D. Sicignano, D. Tardioli, S. Cabrero, and J. L. Villarroel. Real-Time Wireless Multi-Hop protocol in Underground Voice Communication. Ad Hoc Networks, 2011. [10] D. Sicignano, D. Tardioli, and J. L. Villarroel. QoS over Real-Time Wireless Multi-hop Protocol. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, 28:110–128, 2010. [11] W. R. Stevens. Advanced Programming in the UNIX Environment. Addison-Welsey, 1992. Section 3.14. [12] D. Tardioli. Real-Time Communication in Wireless ad-hoc networks. The RT-WMP protocol. Universidad de Zaragoza, October 2010. [13] D. Tardioli, A. R. Mosteo, L. Riazuelo, J. L. Villarroel, and L. Montano. Enforcing Network Connectivity in Robot Team Missions. The International Journal of Robotics Research. doi:10.1177/0278364909358274, Vol. 29, No.4:460–480, April 2010. [14] D. Tardioli and J. L. Villarroel. Real Time Communications over 802.11: RT-WMP. IEEE International Conference on Mobile Adhoc and Sensor Systems, 2007. MASS 2007., pages 1–11, Oct. 2007. 43 ´ Indice de figuras 1.1 Cambio de nodo en funci´on de la calidad del enlace ............... 2 1.2 Comunicaciones con y sin RT-WMP ........................ 3 1.3 Nodo accediendo a internet mediante otro nodo distante ............ 3 2.1 Esquema inicial .................................... 5 2.2 Situaci´on hipot´etica con su grafo y su LQM correspondiente ......... 7 2.3 Arquitectura del protocolo ............................. 8 3.1 Esquema general ................................... 12 3.2 Comunicaci´on entre ath5k raw y RT-WMP ................... 13 3.3 Ejemplo del sistema compilado ........................... 15 3.4 Diferentes definiciones de un macro y ejemplo de su uso ............ 15 3.5 Implementaci´on de una funci´on inexistente en el kernel ............ 16 3.6 Esquema general de la interfaz creada por la pasarela ............. 18 3.7 Direcci´on IP / Datos de nodo RT-WMP ..................... 18 3.8 Ejemplo del fichero de configuraci´on de la pasarela ............... 20 3.9 Biblioteca de acceso a RT-WMP .......................... 24 3.10 Encapsulado de mensajes RT-WMP dentro de UDP .............. 25 3.11 Listado de ficheros en /proc/rt-wmp ........................ 25 4.1 Ancho de banda en redes de diferente tama˜no .................. 28 4.2 Duraci´on de una iteraci´on en el caso peor ..................... 28 4.3 Retraso en la entrega de los mensajes ....................... 29 4.4 Retraso en la entrega de los mensajes + Arbitraje ............... 29 4.5 Secci´on del t´unel de Somport ............................ 30 4.6 Port´atil que hace de pasarela y nodo intermedio ................. 31 C.1 Ancho de banda .................................... 41 C.2 Duraci´on de una iteraci´on en el caso peor ..................... 42 45 ´ Indice de tablas B.1 Retraso medido en cada prueba (nanosegundos) . . . . . . . . . . . . . . . . . . . 39 B.2 Retraso m´ınimo, m´aximo y medio para cada tipo (nanosegundos) . . . . . . . . . 40 C.1 Ancho de banda (Kbps) y porcentaje de mejora . . . . . . . . . . . . . . . . . . . 41 C.2 Duraci´on del intervalo en el caso peor. . . . . . . . . . . . . . . . . . . . . . . . . 42 47 Acr´onimos y siglas ARP Protocolo de resoluci´on de direcciones (Address Resolution Protocol) ATP Fase de autorizaci´on de la transmisi´on (Authorization Transmission Phase) FIFO Primero en entrar, primero en salir (First in, first out) FPU Unidad de coma flotante (Floating-point unit) ICMP Protocolo de Mensajes de Control de Internet (Internet Control Message Protocol) Ioctl Input/Output control IP Protocolo de Internet (Internet protocol) LKM M´odulo del kernel de Linux (Linux Loadable Kernel Module) LQM Matriz de calidad de enlace (Link Quality Matrix) LNL Capa de red de Linux (Linux network layer) MANET Red m´ovil ad-ho (Mobile ad-hoc network) MPM Mensaje m´as prioritario (More Priority Message) MTP Fase de transmisi´on del mensaje (Message Transmision Phase) MTU Unidad m´axima de transferencia (Maximum Transfer Unit) P2P Red entre pares o red punto a punto (Peer to peer) PAP Fase de arbitraje de la prioridad (Priority Arbitration Phase) Procfs Sistema de ficheros de procesos (Process filesystem) QoS Calidad de servicio (Quality of Service) RT-WMP Real-Time Wireless Multi-hop Protocol TCP Protocolo de control de transmisi´on (Transmission Control Protocol) UDP Protocolo de datagramas de usuario (User Datagram Protocol) VoIP Voz sobre IP (Voice over IP) 49