Mostrando entradas con la etiqueta Redes de Telecomunicaciones. Mostrar todas las entradas
Mostrando entradas con la etiqueta Redes de Telecomunicaciones. Mostrar todas las entradas

domingo, 26 de mayo de 2013

[RT] Tarea 8: Redes sensoras


El tema de esta tarea es referente a redes sensoras, el documento seleccionado para su lectura fue:

...
Distributed Control Applications
Within Sensor Networks

Bruno Sinopoli, Courtney Sharp, Luca Schenato, Shawn Schaffert, S. Shankar Sastry,
...

1. Introducción

El paper nos habla acerca dela importancia que están ganando las redes sensoras en aplicaciones de control. El uso de sensores, actuadores y controladores programados para realizar ciertas funciones específicas esta creciendo y muchas veces necesitan combinarse en redes para realizar tareas más complejas, por ejemplo, los controladores del motor de un automóvil conectados entre si.
Así mismo, los MEMS son un tipo de sensores que permiten desplegar de manera económica amplias redes sensoras.
Sin embargo, también se nos muestra el lado impráctico, al momento de mantener una red de miles de sensores  mantener todos los sensores funcionales y conectados a cada momento.
Y como ya sabemos, existen diferentes investigaciones para utilizar este tipo de redes, por ejemplo, en el monitoreo del clima, terremotos, sistemas de transportación, aplicaciones militares y de automatización.
Son importantes las investigaciones que se están realizando para desplegar grandes redes sensoras autoconfigurables, seguras e indetectables; así mismo, combinar la tecnología ad-hoc para su rápido despliegue y la implementación de otras tecnologías como servicios de tiempo, geolocalización, ruteo, etcétera.


2. PEG's


El objetivo de la investigación presentada en el paper es la de diseñar controladores confiables y robustos para sistemas distribuidos. Para su prueba se ha seleccionado una aplicación llamada pursuit-evasion game (PEG) (juego de evasión-persecusión) .

Que consiste en desplegar una red sensora en un entorno donde se desarrolla un juego  de cooperación con un equipo de perseguidores. Para un PEG, la red sensora debe ser capaz de seguir los vehículos y distinguir entre los perseguidores y evasores, y así mismo tener una dinámica de enrutamiento y estructura para ofrecer información a los perseguidores en tiempo mínimo. Dado que el juego se juega en un entorno distribuido, la detección, control y accionamiento necesitan tenerse en cuenta durante el diseño del controlador. También la red debe proporcionar características de seguridad. Por último, ya que cualquier nodo de un red sensora puede fallar, algoritmos de control deben mostrar la degradación del rendimiento esperado.


El framework PEG contiene las características fundamentales para el modelado y diseño de robotica  multiagente y cooperativa que ha sido un área activa de investigación en las últimas décadas. En esta sección.

2.2 Qué es un PEG?


Los PEG son una abstracción matemática derivada de numerosas situaciones que aborda el problema de controlar un enjambre de agentes autónomos en la persecución de uno o más evasores. Ejemplos típicos son las operaciones de búsqueda, rescate y captura, la vigilancia, la localización y el movimiento de partes en un almacén. En algunos casos, los evasores están evitando activamente la detección, como en misiones de captura, mientras que en otros casos, su movimiento es al azar, como en las operaciones de rescate.


En este tipo de juegos, el campo de juego se abstrae de ser un conjunto finito de nodos y movimientos permitidos para los perseguidores y evasores, a estar representadas por aristas que conectan los nodos. Un evasor es capturado si tanto el evasor y uno de los perseguidores ocupan el mismo nodo.

Uno de los problemas más importantes de este juego es el cálculo del número buscadores, es decir, calcular el menor número de perseguidores necesarios para capturar una evasor en un tiempo finito, independientemente de la política de escape utilizada por el evasor, se ha demostrado que este problema es NP-hard. Esta aproximación se limita sólo a los peores movimientos de los evasores, que en general, son excesivamente pesimistas.


Otra área activa de investigación trata el problema del medio ambiente donde se desarrolla el PEG cuando éste es desconocido. En este marco, se requiere una fase de reconocimiento para proceder con la búsqueda. Esta fase consume mucho tiempo y es computacionalmente intensiva, incluso cuando son ambientes simples en 2D. Por otra parte, los sensores inexactos complican a menudo este proceso que requiere un enfoque probabilístico.
Por último, un enfoque reciente de PEG se ha ocupado de combinar el cálculo de los evasores con el reconocimiento del terreno.

2.2 Las redes sensoras en PEG


El uso de un redes sensoras puede mejorar en gran medida el rendimiento de un PEG. Los perseguidores tienen una rango de detección muy pequeño y por lo general, emplean la visión computacional o por ultrasonidos, proporcionando sólo una visión local sobre la zona de interés. Esta limitación hace dificil que una red cooperativa pueda adaptarse a un algoritmo debido a la falta una visibilidad completa que sólo permite políticas de persecución subóptimas.


La comunicación entre los perseguidores puede ser díficil en una área grande. La falta de comunicación, aunque sea parcialmente, entre perseguidores es una interrupción importante en cualquier política de persecución. Con una red sensora, la visibilidad completa del campo y la comunicación en un amplio rango es posible  La búsqueda global  se pueden realizar de manera eficiente para encontrar la solución óptima independientemente del nivel de inteligencia de los evasores. Además, el número de perseguidores necesarios estaría en función exclusivamente del número de evasores y no al tamaño
del campo.
Otro punto importantes a analizar son los siguientes:

  • Tiempo: La noción de tiempo presenta dos problemas distintos, en primer lugar, la coordinación de detección y actuación en el terreno físico requiere ya sea un sentido del tiempo global o la capacidad para resolver diferentes mediciones de tiempo a una significativa representación. En segundo lugar, muchas técnicas de diseño existentes asumen que el cálculo de control y el procesamiento de detección y accionamiento se producen dentro de una cantidad insignificante de tiempo, por lo que requiere nuevas técnicas de diseño y análisis para las redes sensoras.
  • Comunicación: Se espera que una red de sensores tendrá una área espacial significativamente mayor que una sola área de comunicación máxima de un solo sensor. Para que un sensor envíe un mensaje a otro, sensores intermedios deben ser capaces de retransmitir el mensaje. Además el protocolo de comunicación debe ser robusto a cambios en la red.
  • Ubicación: La detección y actuación a eventos en el terreno físico deben estar emparejados con la posición relativa o absoluta del sensor para ser útiles por los algoritmos de control. La ubicación debe ser asumida o deducido.
  • Cooperación: Las tareas requieren el esfuerzo cooperativo de dos o más sensores, como cualquier forma de detección y computación distribuida, se  requieren protocolos y estructuras que proporcionan la negociación, coordinación, y jerarquía de los nodos.
  • Energía: La energía es un recurso valioso en una red sensora. Para garantizar el servicio y rendimiento de una red sensora, el consumo de energía debe ser equilibrado.
  • Seguridad: Para evitar posibles infiltraciones de una red sensora, se debe contar con una capa de seguridad en las comunicaciones que debe proporcionar control de acceso, integridad de mensajes y confidencialidad.
Cómo se ve el juego originalmente

Visibilidad ampliada mediante una red sensora





3. Implementación


El escenario del experimento se compone de una red sensora que se despliega en el campo de juego, los sensores comienzan en un estado de sueño.

A continuación los sensores pasan por una fase de inicialización y calibración para el arranque de sus servicios prestados. Los perseguidores y evasores entran en el campo de juego y se mantienen dentro del mismo.
El red sensora ofrece una variedad de servicios a los perseguidores tales como la sincronización de la hora, localización, identificación de entidad (perseguidor o evasor).
El objetivo de la red es producir estimaciones de las posiciones, la velocidad y la identidad de los elementos en el campo de juego.
Cuando se capturan todas las evasores (se produce una captura cuando un
perseguidor es "lo suficientemente cerca" a él), el juego termina. Una estación base se encuentra fuera del área de juego y proporciona el registro y visualización de los servicios.

3.1 Hardware

La plataforma de hardware fue desarrollada por el grupo TinyOS de la Universidad de Berkeley, y se compone de numerosos y pequeños dispositivos de red y de computación embebida. Cada dispositivo tiene una cantidad de energía limitada, así como capacidad computacional, de almacenamiento y recursos limitados.
El objetivo de cada plataforma de hardware es proporcionar computación, sensores, actuación y comunicación de los recursos integrados en un paquete pequeño.
Las plataformas están diseñados para ser modulares y flexibles, que proporciona la facilidad de reprogramarlas de nuevo y utilizarlas en aplicaciones imprevistas al tiempo que permite la reutilización de código.

Evolución de las plataformas de hardware utilizadas.



3.2 Servicios del sistema


Para el software se utiliza NesC, una nuevo lenguaje de programación de código abierto desarrollado en Berkeley. NesC extiende el lenguaje C estándar con la semántica y sintaxis para arquitecturas basadas en componentes. Los comportamientos se describen con interfaces bidireccionales que proporcionan los comandos para controlar los eventos. Los componentes están conectados entre sí estáticamente para formar un todo, que, cuando se compila permite una mayor optimización y eficiencia.
El sistema operativo proporciona los servicios básicos para la comunicación, así como un planificador de procesos simple y el acceso a los componentes de hardware y sensores; esta diseñado para dispositivos con recursos excesivamente limitados

Capas del sistema y sus relaciones




4. Metodología


4.1 Escalabilidad


Utilizando técnicas ad-hoc, el sistema debe estar preparado para crecer en caso de ser necesario. Los nodos pueden ser activados y desactivados cuando sea necesario.


4.2 Control distribuido


Los sistemas de control distribuído son muy importantes en la computación actual. Desde hace mucho tiempo existen investigaciones que van desde la biología hasta la inteligencia artificial tratando de imitar modelos de la naturaleza, por ejemplo, colonias de insectos buscando comida, bacterias, formaciones de aves, entre otros. En éste caso, los sensores están conectados a un controlador central que toma los datos y los procesa para así tomar decisiones y aplicarlas a todo el sistema.








4.3 Modelos computacionales


Se utilizan una combinación modelos computaciones, donde tal combinación captura el cambio continuo en dinámica del medio ambiente, la distribución de los recursos y la naturaleza discreta del hardware. La combinación incluye eventos discretos, continuos, dinámica de sistemas, los sistemas dinámicos de tiempo discreto, autómatas híbridos, idiomas reactivos síncronos y modelos de flujo de datos.

Los sistemas dinámicos en tiempo continuo son ​​un modelo formal cuyas propiedades clave son la estabilidad y accesibilidad que se pueden deducir mediante métodos numéricos. Sin embargo, para las aplicaciones de control distribuido en redes sensoras, el modelo no es capaz de capturar retrasos en la comunicación, el tiempo entre los relojes, o decisiones discretas. Dado que todas las variables son continuas, es difícil modelar fenómenos concretos.
La naturaleza multimodal de los sistemas se puede describir por un autómata híbrido. Estos sistemas funcionan muy bien tanto para el flujo continuo y de saltos discretos.  Los sistemas de eventos discretos funcionan bien para los cambios de modo o reprogramación de tareas y caracteriza, también permite activar el sistema por eventos.
El modelo de flujo de datos pretende describir la transmisión de datos. En particular, son útiles para la caracterización de varios procesos de comunicación.


4.4 Enfoques de diseño



El enfoque de escalabilidad para dependerá en gran medida de procesamiento distribuido de sensores con el fin de obtener buenas estimaciones de las posiciones y velocidades tanto de evasores y perseguidores. El control y dinámica de cada perseguidor se realiza dentro de la propia perseguidor basado en lecturas de la red, la coordinación de alto nivel se distribuirán entre todos los perseguidores para maximizar la robustez a los ataques adversarios.
Algunas cuestiones relacionadas con el control contribuido han sido abordadas por el sistema híbrido de control. Se combina lo mejor de la teoría de control y la teoría de máquinas de estados
Se supone que los sensores saben que su ubicación en el espacio. Un servicio de localización garantiza que los nodos en las redes desplegadas puedan calcular su ubicación con respecto a unos a otros.
En los problemas de control estándar, los sensores están físicamente unidos a la planta, por lo tanto, se tiene la seguridad de recibir una lectura del sensor en cada paso de tiempo. En el caso de la red sensora, la detección se distribuye, esto significa que puede tomar algún tiempo tener una observación y que ésta llegue a su destino, ya que los paquetes través de la red están sujetos a demoras y pérdidas.


En niveles superiores, el sistema se basa eventos. Los controles reaccionan a uno o más eventos, lo que se llama comportamiento. Los eventos son detectados por la red sensora y se transmiten a un controlador discreto que genera la reacción apropiada. Cada reacción se transmite entonces a cada nivel inferior para cambiar el objetivo de control de acuerdo con las nuevas especificaciones. Los acontecimientos se producen de manera asíncrona, lo que dificulta el análisis formal.

Diseño de los controladores de alto y bajo nivel, y su representación jerarquica.



Conclusiones y crítica

Más que la implementación de un sistema, el paper aborda una investigación sobre el control distribuído de un sistema utilizando redes sensoras. Y a partir de ello se presentan los temas relacionados, así como las plataformas de hardware y software a utilizar.
En lo personal me parece bien que se presenten éstos temas, sobre todo que se aborden los escenarios en los cuales la implementación puede fallar, se hace solamente una mención a que el sistema quedo un poco limitado en capacidad, sin embargo no se muestran los resultados del mismo.
Parece que el experimento esta muy bien diseñado, se toman en cuenta las diversas perspectivas, desde el contexto, el hardware y software, las consideraciones de los sistemas de control y los escenarios de posible fallo; solo faltaría ver la realización del experimento y los resultados para verificar que efectivamente todo el diseño fue el correcto.



Referencias

Sinopoli, B.; Sharp, C. ; Schenato, L. ; Schaffert, S. ; Sastry, S.S. (Agosto 2008). Publicado en Proceedings of the IEEE, Tomo:91, Edición 8, Páginas 1235-1246. Recuperado en Mayo 2013 desde: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1219474

martes, 21 de mayo de 2013

[RT] Tarea 7: Simulación redes ad-hoc

Para ésta semana se debió realizar la simulación de una red ad-hoc. La simulación debe contar con las siguientes características.
  • Llegadas y salidas de nodos utilizando procesos Poisson.
  • Por lo menos un modelo de movilidad
  • Nodos con capacidad inicial de batería
  • Envío de mensajes, el cual consume batería según el radio de transmisión
  • Modelo simplificado
    • La recepción de mensajes no consume batería
    • El radio de alcance es ajustable en cada nodo individualmente
    • Inundación con un TTL que se adapte


Redes ad-hoc

Una red ad-hoc es una red inalámbrica descentralizada, es decir, que no cuenta con un nodo central que controle las comunicaciones, sino que todos los nodos comparten privilegios.

Las redes bajo este modelo son las más simples de construir ya que no se basan en una infraestructura existente. Las tarjetas en modo ad-hoc se configuran con las opciones de fábrica.
Cada nodo participa en el enrutamiento mediante el envío de los datos para otros nodos, y la determinación de qué nodos encaminan los datos se realiza dinámicamente sobre la base de la conectividad de red.

"Se denomina ad-hoc a cualquier conjunto de redes en las que todos los dispositivos tengan el mismo estatus en una red y son libres de asociarse con cualquier otro dispositivo de red ad hoc en el rango de enlace."



El protocolo que rige este tipo de comunicaciones es el 802.11, definiendo todos los parámetros necesarios para establecer la comunicación entre dispositivo inalámbricos. EL principal inconveniente de este tipo de redes radica en el número de saltos que debe recorrer la información antes de llegar a su destino, esto debido a que los nodos pueden conectarse o desconectarse en cualquier momento.



Simulación

Como es de esperarse, la simulación fue realizada en lenguaje Python, utilizando hilos.

Básicamente el script se compone de 3 módulos:

  • Interfaz: Utilizando Tkinter, ayuda a visualizar lo que esta sucediendo en la zona de la simulación.
  • Generador de nodos: Se utiliza una simple función, la cual se corre como un hilo utilizando la librería threading. La finalidad del módulo es agregar nodos a la red emulando un proceso de Poisson, en éste caso el temporizador esta controlado por la función random.expovariate, con un valor lambda de 5.
  • Simulador: Se encarga de arrancar los nodos y movilizarlos uno por uno.

2 clases principales componen los elementos de la simulación:
  • Mensaje: Representa el mensaje que es transmitido durante una conexión entre nodos. El mensaje cuenta con 2 atributos:
    • ttl: Un valor de vida inicial el cual disminuye en 1 cada vez que el mensaje de transmite a otro nodo.
    • estado: Representa si un mensaje aun se puede transmitir. Un mensaje es descartado cuando su valor TTL llega a cero.
  • Nodo: Un nodo capaz de conectarse a la red ad-hoc, los atributos de cada nodo son:
    • id: Número identificador único de cada nodo.
    • color: Color para la visualizacion
    • coord: Coordenadas donde el nodo sera dibujado
    • radio: Radio de alcance del nodo
    • bateria: Bateria del nodo
    • costo: Costo energetico de cada paso
    • velocidad: Velocidad del movimiento
    • vecinos: Vecinos dentro del radio de alcance
    • cola: Cola de mensajes que serán transmitidos
    • estado: Estado del nodo: True=Vivo, False=Muerto
    • instancias: Para guardar temporalmente las referencias a los dibujos del nodo

Los nodos siguen un proceso muy simple en cada paso, los primeros pasos son:
  1. Se calculan los atributos del nodo, los cuales son:
    • Posición inicial (x,y)
    • Radio de alcance
    • Nivel de bateria
    • Velocidad del movimiento
  2. Se inicializa el nodo con los atributos anteriores, de manera transparente se le asignan al nodo otros atributos como:
    • Asignar el ID
    • Asignar el color
    • Consumo energético inicial (1)
    • Lista para almacenar los vecinos
    • Cola de mensajes (5 iniciales)
    • Iniciar el nodo como vivo

Una vez inicializado el nodo, por cada paso se realiza lo siguiente:
  1. Se calcula la siguiente posición del nodo.
  2. Se buscan por aquellos nodos que se encuentren dentro del radio de alcance del nodo (utilizando teorema de Pitágoras)
    • Si un nodo se encuentra a una distancia menor o igual al radio de alcance, dicho nodo entra a la lista de vecinos
    • Mientras no se encuentren 3 vecinos, el radio de alcance ira creciendo poco a poco, dicho crecimiento hace que el nodo consuma más batería por cada paso.
  3. Se transmite el mensaje a los nodos vecinos
    • El mensaje baja en uno el valor TTL
  4. Se dibuja lo que esta pasando en la interfaz
  5. Se modifica el nivel de batería del nodo
    • Si la batería llega a cero, se eliminan sus elementos del canvas, la instancia del nodo y su estado pasa a False, así la simulación lo sacará de la lista de nodos activos y el garbage collector hará el resto.

Video



Código


Referencias

Shaeffer,Elisa. Mayo 2013. Redes Ad-Hoc. Redes de Telecomunicaciones. Recuperado el 20 de mayo de 2013 desde http://elisa.dyndns-web.com/~elisa/teaching/comp/net/adhoc.pdf

martes, 14 de mayo de 2013

[RT] Tarea 6: Geolocalización

Para ésta entrada se pidió realizar un código de geolocalización utilizando triangulación de antenas detectando la potencia de las señales de las señales.

Triangulación

Como su nombre lo dice, el método de triangulación hace uso de trigonometría para determinar la posición de objetos relevantes sobre un área determinada.

Mediante triangulación, se pueden obtener las coordenadas de un punto, por ejemplo, el barco de la imágen.
[1]

Primero, se calcula la distancia existente b entre dos puntos conocidos: A y C.
Se miden los ángulos de los vértices A y C, y aplicando trigonometría, es posible obtener las distancias AB y CB, y por tanto, las coordenadas del punto B.


Trilateración

La trilateración es un método que ha venido supliendo a la triangulación, consiste en conocer de antemano las ubicaciones de los puntos de referencia que se utilizarán para detectar la posición de un objeto en un área.

[2]

Sobreponiendo 3 esferas las cuales pueden representar el alcance de una torre transmisora, por ejemplo, el radio de las esferas representa las distancias de las torres transmisoras al punto que se desea localizar.
Medir los 3 radios puede proporcionar la distancia relativa de las torres al punto seleccionado.


Simulación

Realicé una script en Python que permite simular la localización de un punto mediante trilateración, conociendo de antemano la ubicación de 3 torres transmisoras.

Utilicé como referencia las fórmulas halladas en Wikipedia, se programaron en Python y utilizando la libreria Numpy para facilitar algunos cálculos de álgebra lineal, además basándome en un post el cual se encuentra en las referencias.
Lo demás fue agregar una sencilla interfaz gráfica para ilustrar los resultados.

Se necesita conocer el alcance de la señal de cada transmisor, en éste caso, en pixeles; las coordenadas de los transmisores.
A pesar que el programa sabe la ubicación del receptor, se etiquetará el mismo con las coordenadas obtenidas mediante las ecuaciones de trilateración.

Código
Video


Referencias

martes, 30 de abril de 2013

[RT] Tarea 5: Control de congestión

Para ésta semana se tuvieron que realizar las siguientes 3 actividades:

"Desarrollen para ns-2/3 un módulo que permite
  • Crear topologías
  • Generar “patrones” tráfico 
  • Comparar por lo menos dos diferentes esquemas de control de congestión (inventados por ustedes mismos, no anden googleando ni por ideas ni por código)"

1. Crear topologías y habilitar métodos de ruteo


Código que permite crear topologías de tipo:

  • Estrella
  • Anillo
  • Malla
  • Scale-Free
  • Small-World


Además poder habilitar diferentes métodos de ruteo unicast, multicast y adhoc



2. Generar tráfico

Código que permite generar tráfico sobre UDP o TCP, se puede configurar para seguir distintos patrones y distribuciones de probabilidad para hacerlo más realista.



3. Esquemas de control de congestión

Para el control de congestión, diseñe 2 esquemas muy simples, los cuales detectan una congestión basándose si hay o no pérdida de paquetes y la medida que toman para controlar la congestión es controlar la tasa de transferencia directamente.
Los esquemas se comportarían de la siguiente forma:

  • El primero necesita evaluar primeramente las condiciones de consumo de banda ancha, por eso en una primera etapa comienza con una tasa de transferencia pequeña que aumenta linealmente en pasos iguales. Si no se detecta ninguna pérdida entonces la tasa de transferencia comenzara a aumentar exponencialmente, al doble del paso anterior en cada tiempo, hasta llegar al tope de la cantidad de banda ancha disponible para esa conexion. Cuando se detecte la primera pérdida de paquetes entonces la tasa de transferencia cae hasta un 10%, después todo el proceso comienza de la misma forma, los paquetes perdidos se reenvian al estilo fast-retransmit en la primera oportunidad. Con esto espero que las colas de paquetes se vacíen un poco antes de volver a transmitir a la misma eficiencia que antes.
Comportamiento esperado


  • El segundo comienza con un aumento progresivo en la tasa de transferencia, evaluando las condiciones de la red y el consumo mientras aumenta. La tasa de transferencia esta acotada por el máximo de banda ancha disponible, así que, conforme la tasa de transferencia se acerca al tope, esta comienza a frenarse poco a poco, digamos que se comporta como una gráfica logarítmica. Si se detecta una pérdida de paquetes entonces la tasa de transferencia cae un 30% y vuelve a aumentar de la misma forma que antes. De la misma manera, se espera que las colas de datos se vacíen un poco antes de volver a enviar datos. La recuperación también es rápida adoptando los esquemas de fast-recovery y fast-retransmit de los protocolos TCP.
Comportamiento esperado




Sin embargo, la implementación de los esquemas de control de congestión están muy apegados al diseño de los llamados agentes (que suelen representar protocolos de capa 4 [TCP, UDP]).
La correcta implementación requiere tener conocimientos de programación C++ y si es posible, creación de patches para modificar el código existente en NS-2 en partes específicas.
Dentro de la carpeta donde descomprimimos NS-2 habrá una carpeta con el nombre ns-2.35, dentro se  encuentran ordenados por carpetas los diferentes protocolos disponibles.
Si queremos crear un nuevo esquema, agente o protocolo, debemos crear su carpeta ahí y dentro crear por lo menos 2 archivos:

  • Header (*.h): Que como sabemos, en C++ contiene la estructura del nuevo agente, los métodos y atributos.
  • Código (*.cc): Que contiene el desarrollo de los algoritmos necesarios para manipular las colas de datos, tablas de ruteo, estructuras de los paquetes, mensajes, timers, etcétera. Aqui es donde se implementa todo el código.
El tutorial escrito Marc Greis en http://www.isi.edu/nsnam/ns/tutorial/index.html indica de forma precisa como implementar un nuevo agente, en éste caso, emulando a PING.

El tutorial escrito por Elmurod A. Talipov en http://elmurod.net/en/index.php/archives/157 indica la forma de agregar los nuevos agentes a NS-2 y modificar ciertos archivos para recompilar el código fuente y que estén disponibles para las simulaciones con TCL.

Sin embargo, traté de seguir el tutorial con los ejemplos ahí incluidos y terminaba rompiendo el código fuente de NS-2, además de recibir múltiples mensajes de error al correr el makefile.


Referencias

martes, 26 de febrero de 2013

[RT] Extra: Ataques a redes (Lectura)

La actividad de puntos extra consistió en realizar un pequeño reporte sobre algún documento buscado a través de Google Scholar donde se utilice el simulador NS (NS-2 o NS-3).
El documento seleccionado fue:

Collaborative Change Detection of DDoS
Attacks on Community and ISP Networks* 

Yu Chen and Kai Hwang 

University of Southern California, Los Angeles, CA 90089, USA 
{cheny, kaihwang}@usc.edu 

...

Resumen

El documento introduce el problema sobre el problema de los ataques DDoS. Por lo general las redes comunitarias funcionan bajo el mismo ISP (Internet Service Provider) o se administran bajo un método de organización virtual que se extiende a través de múltiples dominios de red bajo una relación de confianza.

Los ataques DDoS se pueden contrarrestar si los routers dentro de esa red trabajan de forma cooperativa para enviar alertas tempranas para evitar los daños a la red. Entonces el objetivo del trabajo es "proponer una arquitectura de colaboración para detectar inundaciones por ataques DDoS".
Ésto es posible mediante el monitoreo de la distribución del tráfico sospechoso en cierta cantidad de routers  por donde transita el ataque y los cambios que sufre, para ello se desarrolló un nuevo mecanismo CAT (Change-Aggregation Tree) que permite la detección tempran de los ataques.

Para ello se utilizaron simulaciones con NS-2 en una red ISP de dominio simple.

El sistema ofrece un nivel de detección de un 95% con menos de un 1% de alarmas falsas-positivas.

Arquitectura de un ataque DDoS


Introducción

Una red comunitaria pueden ser pequeñas o grandes, desde una LAN hasta WAN, y por lo general forman parte de la infraestructura de clusters, redes colaborativas, redes P2P, servidores se servicios web, etcétera. Por lo general estas conformadas por un gran número de administradores IT.
Los requisito básico en una red es proveer un acceso seguro y confiable a los recursos, ya sean locales o remotos. Los ataques DDoS cancelan este requisito, volviéndose la más peligrosa amenaza para los sistemas distribuidos.

Actualmente existen técnicas bastante simples para detectar un ataque DDoS, por ejemplo, cuando el tráfico de entrada y salida no esta muy balanceado, desafortunadamente cuando se detectan estas condiciones ya es demasiado tarde. 

Si se trata el tráfico de internet como un proceso estocástico, una técnica de detección de cambios secuenciales de puntos fue desarrollada para detectar el inicio de los ataques DDoS. La típica metodología de detección de cambios esta obstaculizada por la falta de precisión en el modelo estadístico utilizado para describir los pre-cambios y post-cambios en la distribución del tráfico de la red. Se utiliza el algoritmo CUSUM debido a su simplicidad y baja complexidad computacional, sin embargo, a pesar de ser un buen método de detección de inundaciones TCP SYN a nivel gateway, no sirve para redes distribuidas donde existe mas de un gateway.

ISP de red central

En esencia, las redes comunitarias son organizaciones virtuales (VO) encima del internet físico. Los miembros de la VO pueden compartir recursos con base en requisitos específicos de la aplicación. Los usuarios no tienen ningún control sobre las redes físicas aplicadas. en este caso, las redes utilizadas son administradas por diferentes ISPs. Esto se suma a la complejidad en la realización de trabajo colaborativo.

La investigación sugiere que una solución total para los ataques DDoS es una defensa a escala mundial
sistema a través de la totalidad de Internet.
Dentro de una red de núcleo único ISP, es factible exigir los routers a cooperar entre sí en la lucha contra los ataques DDoS, para ello se propone un cambio en el esquema de detección mediante un cambio al CAT. 
El CAT se basa en el reconocimiento rápido de un patrón de flujo de tráfico dirigido hacia la víctima
máquina.
La raíz es el último router al borde de la red donde el equipo de la víctima es alcanzado. Cada árbol
nodo corresponde a un enrutador de ataque-tránsito (ATR). Cada arista del árbol corresponde a un enlace entre los ATR. El administrador del sistema asegura que todos los routers puedan trabajar cooperativamente. El CAT servidor conoce la topología de la red.

Los patrones legítimos de tráfico no se presentan con la direccionalidad y características de convergencia.
Por lo tanto, una vez que un patrón de CAT se reconoce más allá de cierto umbral, se ha detectado la estadio muy temprano de un ataque DDoS. El esquema de detección esta diseñado para distribuir la información del ataque. Los ATR recolectan la información y la envían regularmente al servidor CAT que la procesa. En caso de que el trafico sobrepase cierto umbral, entonces una advertencia es enviada al servidor CAT.


Patrones de inundación durante los ataques DDoS

Como sabemos, los ataques DDoS atacan un equipo para denegar el acceso a un servicio. Dichos ataques saturan a la victima y a la red entera con una gran cantidad de paquetes los cuales son imposibles de manejar.
Un atacante simplemente explota la red y la gran magnitud de paquetes provocan el agotamiento del ancho de banda por lo que pueden hacer caer a la victima de su conexión a internet. Para lograrlo los atacantes utilizan direcciones IP falsas o duplicadas.


Simulación con NS-2

Para evaluar el rendimiento del cambio propuesto al CAT, se permitieron variaciones en 3 dimensiones: topología de prueba, tráfico legítimo de fondo y las características del ataque.
Se utilizó un modelo real de una topología de un ISP descargada del la página web del proyecto Rocketfuel de la Universidad de Washington.
Los retrasos en la comunicación fueron uniformemente distribuidos en el rango de 40 a 200ms con un ancho de banda de 100MB.
El tráfico de fondo es generado de mediante métodos estadísticos mediante el análisis real de la trama OC48 del proyecto CAIDA.
Para las características del ataque, se estudio una herramienta real de ataques DDoS llamada Stacheldraht V4. Es una de las herramientas mas representativas de este tipo de ataques.



El rendimiento de la simulación se midió con tres parámetros diferentes: detección de retrasos, precisión en la detección y la proporción de falsos positivos.
Los tres parámetros se midieron en 3 tipos de ataques diferentes: inundación TCP, inundación UDP e inundación ICMP. El promedio del tiempo de detección mide el intervalo de tiempo entre el inicio del ataque DDoS y el tiempo en el cual el servido CAT lanza una alarma de ataque.
La precisión de la detección es evaluada usando tres mediciones: proporción de detección, proporción de falsas alarmas y las características del recibidor.

El esquema CAT detecta el inicio de la inundación DDoS monitoreando la variación en el volumen de tráfico, recolectando los patrones sospechosos y construyendo el árbol CAT periódicamente  Después se necesita decidir si el árbol resultante es debido a un ataque o a las fluctuaciones en el tráfico de la red. La diferencia entre ambos es que el tráfico por fluctuaciones en la red no se propaga muy lejos y no muestran la direccionalidad del flujo y un blanco de convergencia en el proceso.


Un umbral se puede establecer para detectar exitosamente un verdadero ataque de inundación, simplemente se obtiene la suma del conteo de las hojas en el árbol y se divide entre la altura del árbol para evaluar el tamaño del árbol. Este tamaño establece el umbral de detección para los ataques DDoS.

Utilizando un umbral menor a 5, la proporción de detección es casi 100%, y cuando ésta proporción se mantiene por encima del 95% y el umbral en 5, la proporción de falsos-positivos cae de 70% a 0%.



También se estudió la relación entre el umbral de detección y la proporción de tráfico experimentado en los ATR's. En un ataque de inundación altamente distribuido, donde el tráfico experimentado por routers individuales es muy bajo, la situación de inundación no es detectada hasta que el stream de información causan cambios notorios.
Eventualmente el valor de umbral se saturará, entre mas zombies estén involucrados, mayor sera el umbral seleccionado. Con un tráfico mayor a 1MB/s ambas curvas de umbrales se saturarán. Esto significa que se tendrá un umbral de detección más estable cuando la inundación DDoS alcanza un nivel lo suficientemente alto.

Otro problema crítico encontrado es cuan rápido se puede detectar el lanzamiento de ataques DDoS desde un gran número de zombies. Desde que el árbol CAT se puede actualizar con todos los ATR periódicamente  el tiempo de retraso puede incurrir en la actualización del servidor CAT con cambios locales frecuentes detectados por cada ATR's. El servidor CAT necesita tiempo para procesar toda la información si un gran número de servidores esta involucrado. Un retraso mayor a 0.5s  no es tolerable.


Conclusiones

La complejidad de los patrones en los ataques DDoS crece rápidamente  también si una nueva vulnerabilidad en las redes es encontrada y herramientas más sofisticadas de ataque están disponibles, por lo que una solución puede servir en algunas redes y fallar en otras.
Las contribuciones de la investigación realizada son la detección temprana de la ola de ataques DDoS basados en los patrones y las anomalías detectadas en la red ISP, los cambios propuestos en el árbol de agregación pueden detectar las inundaciones DDoS de forma temprana.
El método propuesto de puede desplegar en redes ISP centrales, y el esquema de detección se puede implementar en los routers utilizados en la red ISP bajo la misma autoridad.
Existen ventajas y desventajas entre la proporción de detección y la tolerancia a falsas alarmas, los resultados se verificaron satisfactoriamente y los resultados indican que el sistema es capaz de detectar inundaciones DDoS rápidamente con una alta proporción de detecciones y una baja proporción de falsas alarmas, sin embargo, la precisión esta por ser probada con un prototipo desarrollado y experimentos de referencia en el futuro.

** Las imágenes fueron tomadas del paper.

Referencias:

lunes, 25 de febrero de 2013

[RT] Tarea 4: Experimentos de calidad de servicio

Como se especificó en la entrada:



la tarea de esta semana consistió en analizar la calidad del servicio QoS de una aplicación en internet
Para mi tarea establecí las siguientes condiciones:
  • Stream de video desde http://www.youtube.com
    • Conexión cableada a internet mediante interfaz ethernet
    • Red infinitum
    • Banda ancha promedio de 2.88Mbps de bajada al momento del experimento
    • Video a 480p de resolución.

Los parámetros a analizar son:
  • Latencia
  • Jitter
  • Perdida de paquetes
  • Tasa de transferencia

Los resultados esperados de acuerdo a la teoría investigada son:
  • Latencia: menor a 150ms
  • Jitter: menor a 50ms
  • Perdida de paquetes: menor o igual al 3% del volumen de datos transmitido
  • Tasa de transferencia:
    • Video a 480p con codec FLV o WebM = 1Mbps aprox.
    • Audio con codec AAC o Vorbis = 128Kbps
    • Valor teórico esperado = 1152Kbps o 1.2Mbps aprox.

1. Medición de latencia y Jitter



Metodología

Como primer herramienta para calcular la latencia utilicé el comando ping a la url www.youtube.com.
Escribí un pequeño script en python para automatizar la tarea pues realicé la medición con 300 paquetes.


Se midió la latencia para esos 300 paquetes y se calculo el promedio y la desviación estándar. Después a partir de las 300 mediciones de la latencia se calculó el jitter promedio.

Ejecución

Pantalla de resultados

Resultados


La ejecución produce dos archivos los cuales posteriormente grafiqué, obteniendo lo siguiente

LatenciaJitter

  • Latencia promedio: 47.115ms
  • Jitter promedio: 17.425ms

Podemos ver como la latencia permanece estable, con un promedio de 47ms lo cual significa que el primer parámetro de medición de QoS esta en excelentes condiciones.
Lo mismo pasa con el Jitter, ya que la medición permanece debajo de 20ms lo cual también es excelente.


2. Medición pérdida de paquetes


Después de un rato de pensar que tenía problemas, me sorprendió descubrir que estuvé en un error desde el principio. Intentaba obtener los paquetes de Youtube filtrando UDP y descubrí que youtube utiliza TCP para sus transmisiones. Así que en realidad en un stream de video de Youtube no hay muchas pérdidas ya que el protocolo TCP al detectar un paquete perdido simplemente lo retransmitirá.
Entonces, para comprobar que todo esté en orden voy a medir la cantidad de retransmisiones de paquetes que se hacen durante la transmisión.

Metodología

Primero dediqué la mayor parte de mi banda ancha a Youtube, es decir, cerré otras páginas web abiertas. Despues busqué por el video seleccionado, y esperé.

Después abrimos Wireshark y vamos al menú: Capture > Interfaces

 Seleccionar intefaces

En la ventana emergente seleccionamos la interfaz a escuchar, en mi caso es eth0, y presionamos el botón start.

Elegir la interfaz a escuchar


En la ventana principal, en el campo de texto que dice Filter escribimos TCP

Después rápidamente regresé al navegador, abrí el video, lo configuré a 480p y comencé la reproducción, después solo esperé a que el video terminara de reproducirse.

Resultados

Una vez terminada la reproducción, presionamos el botón Stop the running live capture, nos vamos al menú Statistics > Conversations, en la ventana emergente seleccionamos la pestaña TCP y en la tabla ordenamos los resultados de mayor a menor utilizando la columna Bytes A←B. Así la primera fila será la conversación con más bytes transmitidos, la cual debe ser el stream de video. Hacemos click en esa fila y presionamos botón Follow stream para filtrar solo los paquetes TCP que pertenecen a la comunicación con Youtube.

Conversaciones TCP

Una vez hecho ésto, veremos que en la ventana principal veremos los paquetes de la comunicación con Youtube, veremos también que el campo de texto Filter ha cambiado, ahora dice algo parecido a tcp.stream eq 11 (donde el último número puede variar ya que pertenece a un id interno de wireshark para clasificar las conversaciones). Dejamos ese filtro y escribimos después and tcp.analysis.retransmission. Con ello filtraremos los paquetes que fueron retransmitidos durante la reproducción.

Paquetes retransmitidos

En la parte de inferior de la ventana veremos dos valores, Packets y Displayed, estos valores nos ayudarán a calcular la pérdida de paquetes.
Packets indica la cantidad total de paquetes transmitidos durante toda la conversación, el cual fue de 21062.  Displayed muestra la cantidad de paquetes retransmitidos filtrados, el cual fue de 913 , entonces, haciendo una regla de 3 obtenemos que el porcentaje de paquetes perdidos fue de 4.33%.

Para garantizar una buena calidad en el servicio se necesita tener una cantidad de paquetes perdidos menor o igual al 3% del volumen de datos transmitido, el resultado de esta medición nos indica que la cantidad de paquetes perdidos fue 1.33% arriba de lo permitido, por lo que ya esta fuera de los límites recomendados. Sin embargo la medición permanece por debajo del porcentaje permitido para las líneas ADSL el cual es de 5% del volumen de datos transmitido.


3. Medición tasa de transferencia


Metodología

La tasa de transferencia se analiza desde el menú Statistics > Conversations, en la ventana emergente seleccionamos la pestaña TCP y la tabla la ordenamos de mayor a menor utilizando la columna  Bytes A←B. Así la primera fila será la conversación con más bytes transmitidos, la cual debe ser el stream de video.


Análisis de la tasa de transferencia


Resultados

Aqui nos interesan 3 columnas, las marcadas como  Bytes A←B, Duration y bps A←B.

La columna  Bytes A←B nos indica la cantidad de bytes transmitidos, el cual fue de 14 660 397bytes o  13.95MB aproximadamente, éste es el tamaño del video.
La columna Duration indica la duración de la conversación TCP en segundos, la cual fue de 440.21s, o aproximadamente 7.33 minutos.
La columna bps A←B muestra la tasa de transferencia, la cual fue de 266421.81bps o 266.422Kbps.

Aquí es donde obtuvimos los peores resultados, el valor teórico lanza una tasa de transferencia de 1.2Mbps aproximadamente, de acuerdo a los parámetros de codificación de Youtube; la medición práctica nos indica una tasa de transferencia de 266.422Kbps, es decir, aproximadamente un 22% de lo esperado.

El resultado no sorprende en realidad, ya que la duración real del video reproducido es de 5:33 minutos y la duración de la conversación fue de 7.33 minutos, 2 minutos de retraso.

También podemos ver que el valor teórico recomendado para la configuración del video recomendado es muy alto, posiblemente se utilizó un códec diferente para el video seleccionado.

Conclusiones

  • Latencia
    • Esperado: menor a 150ms
    • Obtenido: 47.115ms
  • Jitter:
    • Esperado: menor a 50ms
    • Obtenido: 17.425ms
  • Perdida de paquetes:
    • Esperado: menor o igual al 3% del volumen de datos transmitido
    • Obtenido: 4.33% del volumen de datos transmitido
  • Tasa de transferencia:
    • Esperado: 1152Kbps o 1.2Mbps aprox.
    • Obtenido: 266.422Kbps

Mientras la conexión con el servidor de Youtube se mantuvo muy limpia, la transmisión del video fue insatisfactoria.
Una alta pérdida de paquetes y tasas de transferencia tan bajas pueden ser indicador de una alta congestión en los servidores de la compañía.
Se concluye entonces que, bajo las condiciones establecidas para el experimento, la calidad en el servicio es insatisfactoria, lo que repercute en la experiencia de usuario.


Referencias:

martes, 12 de febrero de 2013

[RT] Tarea 2: Implementación de un protocolo

Protocolo para el envió de mensajes a un buzón anónimo.

Propósito

El propósito del protocolo que diseñé es el envío de mensajes cortos vía Internet a un servidor que los almacena en el buzón correspondiente a cada usuario.

La aplicación

Se cuenta con un servidor programado en Python utilizando comunicación UDP, para ello utilicé la librería SocketServer. Para aplicar el protocolo UDP se declara una clase llamada UDPHandler que hereda el módulo SocketServer.BaseRequestHandler, que es un módulo con funciones base para procesar las peticiones al servidor pero en este caso especifico que lo quiero UDP.
Dentro tiene un método llamado handler donde se colocan los pasos que seguirá el servidor para procesar cada petición.
Ahora necesito el servidor UDP funcionando y, como lo quiero multiusuario, necesitamos importar la librería Threading, para ello es necesario implementar correctamente la siguiente clase, llamada ThreadingUDPServer que hereda a las clases SocketServer.ThreadingMixIn y SocketServer.ForkingUDPServer. La clase se queda vacía (pass). El threading server correra un hilo diferente cada vez que se conecte un cliente.

Ésta es la forma más fácil, simple y correcta de implementar un servidor UDP multiusuario.

Lo que acabo de explicar quedaría mas o  menos así en sintaxis:


import SocketServer
import threading

class MyUDPHandler(SocketServer.BaseRequestHandler):
def handle(self):
# Como se procesa la peticion
# Pasos definidos por el usuario

class ThreadingUDPServer(SocketServer.ThreadingMixIn, SocketServer.ForkingUDPServer):
pass

El cliente realiza 3 peticiones básicas que son servidas por el servidor:
  • Descargar mensajes: El cliente especifica el ID del buzón para ver los mensajes guardados en el. El servidor lee la base de datos y envía los mensajes uno a uno.
  • Enviar mensajes: El cliente especifica el ID del buzón donde se dejará el mensaje. El servidor guarda el mensaje en el buzón indicado.
  • Obtener buzón: El cliente pide un ID para un nuevo buzón. El servidor genera un ID dinámico ente 1 y 999999.
  • Una opción salir cierra la conexión entre el cliente y el servidor, el servidor continúa corriendo.
Para simular los buzones se utilizan archivos donde el nombre corresponde al ID que se le proporciono al usuario al momento que lo solicito con la opción 3.


Sintaxis del protocolo


Básicamente, el protocolo utiliza 4 datos sencillos dentro de cada "paquete", los datos los nombre de la siguiente forma:
  • Acción: Indica el tipo de petición a servir por el servidor. El dato es de tipo entero.
  • ID1: Reservado para el ID del remitente que envía el mensaje. El dato es de tipo entero.
  • ID2: Contiene el ID del destinatario en el caso del envío de mensajes. En el caso de descarga contiene el ID del buzón a leer. El dato es de tipo entero.
  • Mensaje: Contiene el mensaje a enviar en el caso 2. Contiene el mensaje a descargar en el caso 1. Contiene el ID generado dinamicamente en el caso 3.
El "paquete" del protocolo se representa mediante una tupla de 4 elementos tuple(int, int, int, string), cada  entero ocupa 4 bytes y el mensaje esta limitado a 128 caracteres o 128 bytes, entonces el largo del paquete esta limitado a 140 bytes.
En el caso del empaquetado, si el mensaje es mayor a 128 caracteres entonces es recortado hasta el límite. Si el mensaje es menor a 128 se agrega un caracter de separación ( | ) y el resto se rellena con basura ( . ) porque el tamaño del mensaje es fijo siempre, el caracter de separación le permite al desempaquetador recuperar el mensaje y desechar la basura.

Para codificar los datos se utiliza la librería Struct de python que permite empaquetar una tupla de datos en una representación de bytes utilizando estructuras parecidas a las de C. Se necesita especificar el formato de codificación el cual es "i i i 128s" (int, int int 128string). Después utilizando la función Struct.pack(*datos) los datos se convierten en su presentación en bytes.

Después de empaquetar los datos se encaminan al servidor utilizando un canal UDP y especificando el host y puerto del servidor (localhost, 8080)

El desempaquetado realiza el proceso inverso, con el mismo formato de codificación pero en éste caso es para recuperar la información del paquete. Para ayudar a darle forma a los datos de nuevo se utiliza un diccionario donde se leen los elementos de la tupla recuperada, aquí es donde el caracter de separación agregado en el empaquetado ayuda a recuperar el mensaje y desechar los caracteres de relleno. Los campos del diccionario son: datos["accion"], datos["ID1"], datos["ID2"], datos["mensaje"].


Semántica del protocolo


Como ya expliqué, existen 4 comandos dentro de la aplicación, el servidor solo responde a 3 comandos.

El comando Descargar es especial, es la única opción que permite enviar varios paquetes a la vez alternadamente. Es decir, del lado del servidor, si se desea leer un buzón y el buzón contiene más de un mensaje entonces se leerá el buzón hasta el final y los mensajes se almacenarán en un buffer temporal (list), después por cada mensaje se armará un paquete y se enviarán uno a uno, al final se añadirá un paquete adicional con el mensaje EOT (end-of-transmision).
Del lado del cliente, la aplicación pedirá el ID del buzón que se desea leer y se guardará en el campo ID2 y el campo acción se rellenará con el número 1, los campos ID1 y mensaje permanecen vacíos  La aplicación enviará la petición, creará un buffer temporal (list), y esperará el stream de información. Una vez comenzado el stream desempaquetará todos los mensajes y buscará por la expresión EOT, cuando sea recibida comenzará a vaciar el buffer mostrando al usuario uno a uno los mensajes en la pantalla.

El comando Enviar pide al usuario el ID del buzón destinatario y se guardará en el campo ID2, se pedirá también el mensaje que será empaquetado y se guardará en el campo mensaje. En campo acción se guardará un 2 y el campo ID1 permanecerá vacío.
Del lado del servidor, desempaqueta y recupera la información, buscará por el buzón indicado en el campo ID2 y si existe se abrirá para guardar el mensaje

El comando Obtener no pedirá ningún dato, enviará un paquete donde solo el campo acción contendrá un número 3, los demás campos estarán vacíos.
Del lado del servidor se desempaquetan y recuperan los datos, se generará un ID dinamicamente (random.randint). El servidor responde con paquete igual, solo que ahora en el campo mensaje irá el ID correspondiente al buzón creado y asignado. El usuario puede compartir éste ID para que le envíen mensajes o para recuperar los mensaje de su buzón.

Salir cierra la conexión entre el cliente y el servidor.


Uso de mensajes


Existe un manejo básico de errores y excepciones.

En Descargar el cliente no cuenta con soporte. Del lado del servidor, si  no existe el buzón, se enviarán los mismos paquetes de la misma forma, un stream de 2 mensajes, el primer mensaje contiene la expresión "[X] Error, se intentaron decargar los mensajes de un buzon inexistente (buzon=ID2)", el segundo es la expresión "EOT". El cliente recibirá los datos como si se tratará de una descarga normal pero recibirá el mensaje de error.

En Enviar el cliente no cuenta con soporte. Del lado del servidor, si no existe el buzón se regresará un paquete con el mensaje "[X] Error, se intento dejar un mensaje en un buzon inexistente (buzon=ID2)". El cliente desempaqueta y recupera la información y muestra el mensaje de error en pantalla.

En Obtener no se cuenta con soporte de ambos lados. El servidor se encargará de crear siempre un ID y enviarlo.

De forma general, si hay un error de conexión en ambas partes se genera el mensaje "[X] Error al enviar la peticion (error=ErrorCode)", donde el error code corresponde al código de la excepción capturada por Python en los bloques try...except...

El servidor almacena un LOG de actividades, con los siguientes mensajes.
  • Operación exitosa:
    • [O] Se decargaron los mensajes del buzon [ID2]
    • [O] Se dejo un mensaje en el buzon [ID2]"
    • [O] Nuevo buzon creado [id=ID2]
  • Operación fallida (el servidor los envía como cualquier paquete):
    • [X] Error, se intentaron decargar los mensajes de un buzon inexistente [buzon=ID2]
    • [X] Error, se intento dejar un mensaje en un buzon inexistente [buzon=ID2]
    • [X] Error al enviar la peticion [error=ID2]
El cliente muestra los siguientes mensajes, pero no los almacena en ningú lado:
  • Operación exitosa:
    • [O] Se decargaron [NUM] mensajes
    • [O] Se dejo un mensaje en el buzon [ID2]"
    • [O] Su nuevo buzon es [%s]
  • Operación fallida (el cliente los recibe como respuesta normal del servidor):
    • [X] Error, se intentaron decargar los mensajes de un buzon inexistente [buzon=ID2]
    • [X] Error, se intento dejar un mensaje en un buzon inexistente [buzon=ID2]
    • [X] Error al enviar la peticion [error=ID2]

 

Diagramas







Ejecución





Código

protocolo.py


cliente.py



servidor.py


Referencias: