Reporte - Aplicación de Redes Sensoras

Para esta entrada se leyó el siguiente paper y se escribió un pequeño resumen acerca de lo más importante que ahí se trata:

Underwater Sensor Networking: Research Challenges and Potential Applications

Autores: John Heidemann, Yuan Li, Affan Syed, Jack Wills, Wei Ye

El uso de redes sensoras en ambientes marítimos tiene grandes aplicaciones como el monitoreo de la actividad en yacimientos de petróleo, monitoreo de actividades sísmicas o simplemente controlar robots que se desplacen por el agua.

La idea central del paper es trasladar todo lo logrado de estas redes en el ámbito terrestre a el ámbito marítimo, es decir reproducir las mismas condiciones de conexión (las amplias zonas de cobertura), el bajo consumo energético, la fácil comunicación entre nodos, la gran población, el precio (en el paper mencionan 100 USD por nodo ), todo esto es lo contrario en el apartado marítimo, pequeñas zonas de cobertura, la comunicación generalmente se hace hacia un nodo central, la población es pequeñas y el alto precio (mencionan +10K USD por nodo).

La idea es tratar de acercar lo más posible el aspecto marítimo a las condiciones que se tienen en el ámbito terrestre.

Se basan en el desarrollo de un sistema de monitoreo de yacimientos de petróleo, lo hacen solo con el fin de basarse en algo para explicar y también en el hecho de que esta opción es más barata y eficiente que el sistema tradicional.

Los principales desafíos son trasladar lo que se tiene de manera terrestre a marítimo, el primer desafío es la comunicación inalámbrica ya que mientras en el lado terrestre se puede usar wifi o bluetooth, dentro del mar la transmisión de las ondas de radio en el agua no es muy buena y suele limitarse a 1 máximo de alcance.

Debido a esto la opción más fiable es “Telemetría Acústica” donde la comunicación se hará por medio de ondas de sonido que son más propagables dentro del agua que las de radio.

El segundo punto es que debido al cambio de medio de comunicación la velocidad de transmisión disminuye, de la velocidad de la luz (3x10⁸m/s) a la velocidad del sonido (1.5x10³m/s), por lo que el flujo de información se vería afectado inmediatamente.

Otro punto desafiante es el manejo de energía,  ya que los nodos terrestres son más sencillos y por lo tanto consumen menos energía todo lo contrario de los sensores que se usaran bajo el agua ya que son más complejos y más grandes, por lo que su consumo de energía es mucho mayor.

En la arquitectura del sistema que plantean, se usan cuatro nodos diferentes y la imagen siguiente es la que toman ellos como referencia para la construcción de su red sensora:

Los sensores ubicados casi al fondo del mar son los encargados de obtener la información de los movimientos sísmicos o yacimientos de petróleo y se comunican con los demás de manera acústica, lo que se encuentran en la parte más alta se conectan directamente con estaciones que salen del agua y que son operables por personas, además están conectados a internet para compartir información.

Y los monitos azules suponen robots sumergibles que son capaces conectarse directamente con los demás nodos y sensores para compartir información de manera acústica.

Los nodos siempre estarán estáticos para reducir los costos en la movilidad de los nodos además al tratarse del mar las condiciones ambientales pueden cambiar mucho por lo que algunos nodos se pueden perder, dañar o simplemente dejar de funcionar, por lo que se emplea un sistema de comunicación redundante para que la información que un nodo envía se reenvíe a todos los demás, así, si pierde ese nodo no significará grandes problemas para todo el sistema y será una falta fácil de reparar.

Todo lo demás que se menciona son configuraciones necesarias para la instalación de este sistema por  lo que no son de relevancia su tratamiento aquí.

Conclusiones:
Según lo que dice el paper, aplicaciones de este tipo aún son muy poco explotadas por lo que podría ser un buen punto de investigación.
Además de que las alternativas que se usan actualmente son mucho más costosas y menos eficientes que la mayoria, por ejemplo muchos de estos sistemas se comunican por medio de cables, algo que no es muy confiable dado a que se esta tratando en un medio físico para el cual los cables no si hicieron.
Una pérdida en un cable, podría garantizar la pérdida de mucha información además de tiempo y dinero solo para la información, ya que además sería necesario repararlo y esto resultaría en más tiempo y dinero.

Referencias:

"Underwater Sensor Networking: Research Challenges and Potential Applications", " John Heidemann, Yuan Li, Affan Syed, Jack Wills, Wei Ye ", http://ftp.isi.edu/~johnh/PAPERS/Heidemann05b.pdf 

Actividad #11 Lab - Satélites

Aplicaciones
Las Aplicaciones de comunicaciones satelitáles son muchas. Algunos de las más importantes son:

1. Navegador
Con el canal ascendente se realizarán las peticiones (páginas web, envío de e-mails, etc.) a través de un módem de RTC, RDSI, ADSL o por cable, dependiendo de tipo de conexión del que se disponga. Estas peticiones llegan al proveedor de Internet que los transmite al centro de operaciones de red y que a su vez dependerá del proveedor del acceso vía satélite. Los datos se envían al satélite que los transmitirá por el canal descendiente directamente al usuario a unas tasas de transferencia que se mide en Kbyte/s.

2. Televisión
es un método de transmisión televisiva que consiste en emitir una señal de televisión emitida desde un punto de la tierra y retransmitirla desde un satélite de comunicaciones y existen tres tipos de televisión por satélite que son:
Recepción directa por el telespectador (DTH), recepción para las cabeceras de televisión por cable (para su posterior redistribución) y servicios entre afiliados de televisión local.

3. Rastreo satelital
Este servicio permite localizar vehículos, personas y/u objetos en cualquier lugar del mundo. Para hacer uso del rastreo satelital se necesita tener un dispositivo habilitado con GPS y por medio de una triangulación de señales emitidas por 27 satélites geoestacionarios alrededor del planeta. 

4. Estaciones Climatológicas
Se usan para estar monitoreando corrientes de aire, olas de frío, corrientes marítimas (ciclones, huracanes, etc.) 

Otras aplicaciones pueden ser:

• Teledetección de naves.
• Detección de cambios en relieves terrestres.
• Redes Celulares.
• GPS

Seguridad
Los mecanismos de seguridad que se emplean en muchos satélites, son la encriptación de la información usando diferentes algoritmos y/o mecanismos de compresión de información.


Métodos de Intercepción
Un método que se usa para interceptar comunicación satelital, es debido a que los algoritmos en algunos casos se conocen las soluciones, el trabajo para que los individuos puedan penetrar en esta información se facilita, lo único que se necesita es conocer la posición actual del satélite del que se desea obtener la información, ya que en la mayoría de los casos se encuentran moviendose constantemente.

También se puede hacer mención de una red de espionaje que surgió a partir de la segunda guerra mundial, pero fué público hasta 1976, que se dedica a capturar comunicaciones por radio y satélite, llamadas telefónicas, fax, e-mail, etcétera, en casi todas las redes del mundo.
Se supone que el fin de todas estas operaciones es encontrar pistas del narcotráfico, terroristas, es decir se supone que es con el fin de preservar la paz.
La controlan la UKUSA(EU, Canadá, UK, Australia y Nueva Zelanda).

Razones por la cual se quieren interceptar...

• En las aplicaciones militares, la información que se transmite son datos del país, proyectos, investigaciones, esa es la razón por la cual se quiere interceptar, ya sea para atacar o defender.
• Otra razón es para obtener tele de paga gratis de los satélites de tv.

Básicamente todas las razones son robar información de cualquier tipo para después utilizarla con propósitos negativos o positivos.

_________________________________________________________________________________

Referencias:
http://es.wikipedia.org/wiki/ECHELON
http://www.suparco.gov.pk/pages/applications-satellite.asp
http://www.satellitetoday.com/via/features/Satellite-And-Secure-Communications-A-Strategic-Combination_175.html

Geolocalización (Trilateración)

Para esta entrada se hace uso del método de Trilateración, la opción del método gráfico donde se obtendrá aproximadamente la posición.

La trilateración es un método que se utiliza para determinar la localización de un punto basandose en la distancia de por lo menos otros tres puntos conocidos, sin la necesidad de conocer ángulos (esto si es triangulación).

Para la demostración estoy usando un html con javascript y googlemaps, donde se estan suponiendo valores(solo para demostrar el método).

Se trata de modelar un sistema con tres puntos de acceso wifi, donde se marcan sus posiciones y se dibuja un circulo con la intensidad de la señal que llega hasta el punto a localizar para cada router (en la realidad se  puede calcular la distancia basandose en la velocidad de las ondas de transmisión, calculando el tiempo que tarda en repetirse una señal basandose en la ecuación de v = t/d).

Al dibujarse las tres zonas de cobertura que llegan al punto a localizar se intersectan en un mismo punto las tres, ahí se supone que se encuentra el punto a localizar.



Una captura del mapa que se genera a partir del html anterior:

________________________________________________________________________________
Referencias:
Trilateración[PDF]
http://en.wikipedia.org/wiki/Trilateration
http://www.monografias.com/trabajos18/gps-solucion/gps-solucion.shtml

Actividad #10 Lab - Infographic Seguridad en Telefonía

Seguridad en Telefonía | Create infographics

_________________________________________________________________________________Referencias:

http://alt-tab.com.ar/wp-content/uploads/estandaresmoviles.png

http://www.monografias.com/trabajos75/tecnologias-gsm-cdma-tdma-gprs/tecnologias-gsm-cdma-tdma-gprs2.shtml

http://es.wikipedia.org/wiki/Telefon%C3%ADa_m%C3%B3vil_3G

https://es.wikipedia.org/wiki/Telefon%C3%ADa_m%C3%B3vil

Puntos Extra - Infographic Satélites

SATÉLITES | Create infographics

_________________________________________________________________________________

Referencias:

http://es.wikipedia.org/wiki/Sat%C3%A9lite_artificial

http://www.aero.upm.es/departamentos/economia/investiga/informe2008/satelites.html

http://www.upv.es/satelite/trabajos/pract_14/imagen/tabla0.gif

http://www.neoteo.com/images/Cache/8F8Cx900y900.jpg

Congestión/Tráfico en redes con ns-2

La conexión que se estableció es simple, solo son dos nodos y se crea una conexión udp, por lo que podría pasar por un servicio de VoiP, o al menos es la misma idea:

El codigo para la simulación ns-2, es muy parecido al que se ha estado usando en las entradas anteriorres:



Faltaron las pruebas de rendimiento... :/

Actividad #9 Lab - Ahorro de Energía (lifetime)

Para esta tarea, se realizó un resumen del siguiente documento:

Maximum Network Lifetime in Wireless Sensor Networks with Adjustable Sensing Ranges

Autores: Mihaela Cardei, Jie Wu, Mingming Lu, Mohammad O. Pervaiz

El documento habla acerca de mecanismos para extender o como optimizar la vida útil o tiempo de actividad de una red inalámbrica (cuando se están usando baterías) esto debido al alto consumo de energía al transmitir datos o al tratar de conectar con nuevos nodos.

Debido a que las redes inalámbricas son muy dinámicas en cuanto a la conexión con otros nodos/clientes, es decir la mayoría de las veces no se tiene un límite de usuarios por lo que el consumo de energía puede variar mucho además de esto las variados posiciones que los nodos pueden tomar hacen que el uso de una topología para tener más orden sea más complejo.

Para estos casos, los limitantes son el tamaño (capacidad) de la batería y el peso de esta, generalmente a más capacidad más peso, por lo que actualmente esto impacta directamente en el tiempo de vida de una red de este tipo (sobre todo en dispositivos móviles) ya que siempre se busca la movilidad.

Los mecanismos para extender la vida de estas redes se pueden clasificar en dos tipos:

·         Manejar la activación y desactivación de ciertos nodos.

·         Ajustar la transmisión de datos o el rango que cubre la red.

Algunos problemas que se deben repasar para llevar a cabo el punto central del documento, son los algunos ya conocidos como:

·         Área de cobertura: el objetivo es cubrir cierta área de interés.

·         Puntos/objetivos a cubrir: Dar servicio de cobertura a ciertos nodos.

·         Problemas de cobertura: Determinar el máximo tráfico que puede viajar dentro de la red.

Algunas soluciones propuestas a estos problemas en otras ocasiones, una de ellas es:

·         Una correcta distribución de nodos y protocolo (manejando la activad de la red en rounds), estos nodos se activan para cubrir cierto espacio (donde se requieren conexión) mientras los otros se desactivan porque no se requiere conexión.

El punto aquí es como determinar el número óptimo de nodos para satisfacer las necesidades de la red, como determinar los rounds y en qué punto se debe de cambiar de uno a otro, la posición correcta de estos nodos, la transmisión de datos, todos estos puntos son necesarios con el fin de optimizar el consumo de energía y con esto alargar la vida útil de la red.

El problema planteado (de manera muy general) más formalmente se puede definir de la siguiente forma:

Se tiene cierta cantidad de nodos ubicados de manera aleatoria con el fin de cubrir ciertos objetivos, cada nodo tiene su consumo inicial de energía y la capacidad de ajustar la intensidad de su señal (se definen n opciones). El nodo central tiene la capacidad de conectarse a cualquier otro nodo.

Y se necesita un método para calcular la relación de cobertura entre un nodo y un objetivo (cliente), es decir si la distancia Euclidiana entre el nodo y el cliente no es mayor a una distancia dentro del área de cobertura original.

Con esta información, si la distancia es menor que la cubierta originalmente, se puede modificar para que se disminuya intensidad y así reducir el consumo de energía, en caso de lo contrario se recalcula un nuevo nodo, y se repite el proceso para tratar de disminuir la intensidad de su señal.

La idea de problema se puede aclarar con la siguiente figura:

Donde las s_n son los nodos, los t_n son las clientes/objetivos y las r_n son las opciones de intensidad.

  

Para la obtención de resultados sobre este problema, en el documento se proponen y se aplican tres métodos heurísticos (LP-based heuristic and greedy-based heuristic(centralized and distributed) ) creados por ellos mismos, los métodos se aplican sobre el planteamiento del problema como Programación Entera.

Dos de los métodos se ejecutan en el nodo central, mientras que otro se ejecuta en los nodos con el fin de obtener diferentes perspectivas y nombrar el “más” correcto.

Después de las respectivas simulaciones, los resultados se pueden categorizar de la siguiente forma:

En la figura se muestra el tiempo de vida útil de la red, obtenida de los tres diferentes métodos variando el número de nodos.

En esta figura se muestra como varía la vida útil de la red al modificar la intensidad de los nodos.

Conclusiones

La idea que se propone es buena al tratar de economizar el consumo de energía sobre todo si se trata de dispositivos dependientes de una batería, pero como lo dije en la entrada anterior, los resultados de una simulación pueden resultar engañosos ya que es muy difícil el replicar completamente el comportamiento de cierto medio, por lo que los resultados obtenidos en una simulación pueden no ser los mismos al aplicarse los métodos en un contexto real.

Otro punto, si la idea es disminuir el consumo de energía para alargar la vida útil de la red, según yo resulta contraproducente el realizar cálculos extras para poder aplicar los métodos que se mencionan en el documento, obtener los resultados y tomar decisiones. Estos cálculos extras se reflejaran directamente en el consumo de energía ya que antes no se hacían y al parecer esto no se tomó en cuenta en el documento.

________________________________________________________________________

Enlaces:

http://www.cse.fau.edu/~mihaela/HTML/PAPERS/WIMOB_2005.pdf

Actividad Lab. #8 - Congestión de Redes

Resumen de:

Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC

Autores: Dieu Thanh Nguyen and Joern Ostermann

IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007

Mencionan que en la actualidad la demanda del video streaming ha crecido en gran medida, ya que la mayoría de los servicios que hay en internet ofrecen de diferentes formas contenido presentado de esta forma, como puede ser video streaming de servicios como youtube, dailymotion donde el video se descarga normalmente a nuestra computadora mientras se reproduce o servicios de video on demand donde el video se descarga y se “decodifica” para que lo podamos ver, o también video streaming de transmisiones en vivo, donde puede ocurrir algo parecido al video on demand.

Cada una de estas formas de prestar el servicio de streaming acusa un congestionamiento o saturación de la red, ya que la mayoría de las aplicaciones consumen la mayor parte del ancho de banda que se encuentre disponible dejando sin recursos a otras aplicaciones o usuarios incluso afectando a sí mismos si el ancho de banda no es el adecuado que se ve reflajado como pérdida de paquetes, retrasos, etc.

La propuesta de este paper es una especie de algoritmo para controlar en gran medida el congestionamiento de las redes al utilizar servicios de streaming, la idea que proponen es que este algoritmo se encuentre en funcionamiento directamente en los servidos de las aplicaciones de streaming y no en los clientes (que sería lo más entendible), se busca que este algoritmo sea capaz de optimizar totalmente el flujo de datos teniendo en cuenta las carencias de la red del cliente que se conecte para así no saturar su propia red ni la del cliente, y tener más oportunidades de ofrecer un mejor servicio al momento de la conexión de un gran número de clientes a la vez.

Un aspecto importante a mencionar en el paper es el formato/codificación para video que proponen para mejorar el flujo cuando se hace streaming, que ya desde hace tiempo varias organizaciones han buscado su estandarización y que al parecer a la fecha la norma se quedó en H.264/AVC.

Estos formatos permiten organizar la información contenida en el video de manera que se pueden producir grandes calidades de imagen a menores cantidades de espacio, debido a sus mecanismos de compresión/descompresión por lo que son ideales para aplicaciones para hacer streaming.

Arquitectura del sistema propuesto

Debido a que las aplicaciones de video streaming se ejecutan usando UDP como protocolo de transporte y no TCP, se desaprovechan algunas opciones de este último como el hecho de poder reducir la latencia mediante retransmisión de paquetes, además el protocolo UDP no provee mecanismos para controlar la congestión de la red (TCP si lo hace) y al querer implementar algo para arreglar esto, es necesario que lo que se cree se ejecute en la capa de aplicación del UDP.

Para la estimación del ancho de banda disponible y evitar la congestión de la red, el algoritmo propuesto identifica los cuellos de botella, es decir los puntos en los que la conexión se reduce considerablemente evitando el flujo de la información, con estos embotellamientos detectados procede a disminuir la carga del flujo de información con el fin de no presionar el embotellamiento y causar más caos, y recalcula estos embotellamientos constantemente para decir el tamaño del flujo.

Debido a que la estimación del ancho de banda puede fallar (se calcula el ancho de banda disponible pero la información de este llega retrasada por lo que el flujo de datos a enviar puede no ser el correcto en ese momento), también se propone un mecanismo que actúe en caso de que este error ocurra. La idea es tomar todos los paquetes recibidos y ordenarlos según su prioridad, debido a que el dato de la estimación del ancho de banda puede no ser correcto, estos paquetes se comienzan en enviar de manera que los de mayor prioridad sean los primeros y después los de menor prioridad.

Esto es debido a que el decodificador del video si puede reconstruir la estructura del video a partir de los paquetes con mayor prioridad (lo hace disminuyendo la calidad de video o con breves pérdidas de calidad) y no puede hacer esto partiendo de los paquetes con menos prioridad.

Esto se hace así con el fin de que si el ancho de banda no es el adecuado, solo se pierdan los paquetes de menor calidad y la transmisión del video pueda continuar.

Una imagen de la simulación del sistema con ns-2, donde se espera hacer streaming desde el servidor al cliente, el enlace entre las dos partes de simula utilizando dos routers (R1 y R2) y el cuello de botella será el el menor ancho de banda que produzca alguno de estos dos routers (1200kbit/s). El protocolo de envío de paquetes es UDP.

Los resultados de la simulación anterior comparándolo con los manejos de TCP y UDP se pueden ver en la siguiente gráfica:

Conclusiones

En conclusión se puede decir que la idea de estos tipos es buena, aunque se puede mejorar utilizando un sistema parecido pero ejecutándose en los clientes y que interactúe con el del servidor, de esta manera se puede obtener mayor precisión en los datos para los cálculos de los anchos de banda o el envío de información.

Y aunque a simple vista los resultados pueden ser favorables, un escenario simulado no ofrece con exactitud los mismos factores de un escenario real, por lo que el aplicar este sistema en escenarios reales puede que no arroje los mismos resultados que se muestran anteriormente.

_________________________________________________________________________________

Referencias:

Dieu Thanh Nguyen and Joern Ostermann, "Congestion Control for Scalable Video Streaming Using the Scalability Extension of H.264/AVC", IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 1, NO. 2, AUGUST 2007
Link al paper -> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04276656

Actividad #6 : Topologías de Redes con ns-2

Para esta vez la tarea es tratar de lograr topologías de redes parecidas a alguna forma conocida, formé esta con el simulador de ns-2, conocida como "estrella":

El código de ns-2 para lograr esta topología:



Para formar topologías nuevas, partiendo de la anterior, podemos crear los scripts de ns-2 desde un script de python que reciba unos cuantos parámetros y que posterior los ejecute.

Los scripts se crearían a partir de impresiones de texto archivos de txt con la extensión .tcl de ns-2, su ejecución podría ser con alguna llamada al sistema.

Partiendo de querer crear una topología de estrella, la idea podría ser esta:



La salida de este script es la misma que el script mostrado de ns-2, solo con cambios en el numero de nodos que se manejan.

Para crear otras topologías se pueden tomar como referencias otros patrones en la forma de conectar los nodos o inlcusive conectar todos los nodos de manera aleatoria a ver que sale :P.

Actividad #4 - Métricas de Calidad de Servicio

El experimento que se realizó para la clase, LINK_EXPERIMENTO contempla las siguientes métricas para medir la calidad de servicio de la conexión a internet.

Latencia o ping
Se puede explicar como el tiempo de respuesta entre dos puntos cuando se están enviando paquetes, que puede ocurrir debido a que toman la ruta menos corta para llegar al destino, que toman una ruta muy congestionada o también debido a su posición en las colas de envío/recepción.

Latencias muy grandes pueden resultar en pérdidas de conexión, especialmente durante una sesión de excesiva transmisión de datos como, llamadas VoIP, juego online, videos en streaming, etc.

Durante el experimento las latencias obtenidas con ping, era muy alto, tal vez por eso la sesión de hangout se cortaba a cada rato y aunque se recuperaba la conexión se volvía a perder.

Cantidad de paquetes perdidos
Se refiere a la cantidad de paquetes que tras ser enviados, no llegan a su destino debido a errores durante la encapsulación o a una incorrecta ruta de destino.

Esto se puede ver reflejado en llamadas VoIP como deformaciones/errores/manchas en la imagen o ruidos extraños en las voces. (al menos eso fué lo que me paso a mi :P).

Estas manchas o píxeles de colores estuvieron presentes la mayoría de la sesión del experimento.

Jitter
Los paquetes enviados desde cierta parte pueden llegar con diferentes retrasos hacia su destino, este retraso varía dependiendo de la posición del paquete en la cola que se va formando durante una transmisión de datos.
Según wikipedia, jitter se le denomina a la forma en que varía temporalmente el envío de señales digitales.
Básicamente es un cambio indeseado de cierta señal, que se considera como un ruido que afecta a esta señal provocando retraso en la recepción de los paquetes.

En el experimento esto se veía reflejado como lag durante la videollamada de hangout, la imagen se movía más lento de lo normal y la voz no iba acorde al movimiento de los labios, estaba muy retrasado y desfasado.

Una posible solución a esto, es la de crear un pequeño buffer de los paquetes y mostrarlos con un retraso para tener algo mas normalizado, pero contando con un retraso para poder obtener y organizados todos o la mayoría de los paquetes

_________________________________________________________________________________
Referencias:
http://en.wikipedia.org/wiki/Quality_of_service
http://www.ciscopress.com/articles/article.asp?p=357102
http://www.slideshare.net/prestonj_jag/calidad-de-servicio-en-redes

Experimento QoS

Estas pruebas se realizaron para medir la calidad de los servicios de la conexión a internet durante una sesión de Hangout de Google, en donde solo estaban conectados dos participantes.

Las métricas que se usaron para la medición del QoS fueron:

• Latencia(ping)
• Cantidad de paquetes perdidos
• Jitter

Estas están descritas en la entrada del laboratorio relacionada con esto: 

Cabe resaltar que durante los últimos días he estado teniendo dificultades con mi conexión a internet, por lo que la sesión de hangout era intermitente (conectaba y desconectaba a cada rato) y esto se puede ver reflejado en las pruebas.

Para las pruebas de QoS se hizo uso de la aplicación Wireshark y algunas herramientas de Windows.

Latencia

En la primera actividad se utilizó la herramienta que todos conocen para medir el ping o latencia en Windows, desde la terminal se escribe el comando "ping" seguido de la ip con la que se desea hacer la prueba, esto nos arrojará primeramente si estamos conectados o no, y posteriormente si lo estamos nos dara el tiempo de respuesta que tarda en hacer el envío y recepción de paquetes.

 Una gran latencia puede repercutir en la pérdida de la conexión, como en este caso tal vez eso estaba afectando a la sesión de hangout.

Cantidad de paquetes perdidos
Esto es fácil de entender, simplemente cuando se establece una conexión se estan constantemente enviando y recibiendo paquetes, la pérdida de paquetes ya sea por errores de encapsulación o porque su destino no es seguido correctamente,hace que la sesión se afecte por decir esto se puede reflejar en la videollamada de hangout como pérdidas parciales del video enviado o recibido, o audio entre cortado.
Para esta prueba se uso wireshark  y el filtro "tcp.analyse.lost_packets" y aquí esta el resultado:

Cómo se puede observar en la imagen, había constantes errores duarante la sesión de la videollamada y esto repercute en pérdida de la calidad de la imágen y el sonido.

Jitter
Como se mencionó en el lab, durante una conexión se envían y reciben un montón de paquetes con al información y jitter se refiere a la cantidad de paquetes que sufren un retraso durante su envío o recepción debido a su posición en las colas de envío o recepción.
La prueba si hizo con wireshark y aquí los resultados:

Esto se puede reflejar en la videollamada cuando se registra un lago en los movimientos que realice la persona o lag en la voz de la persona, donde lag me refiero a retrasos.

Esto afecta en gran medida en los videojuegos, debido a que grandes retrasos en los paquetes afectan en la visualización en tiempo real de las imágenes y hace frustante la sesión.

Transmisión de Datos
Otra prueba que hice fue la transmisión de bits durante la sesión, con esto se puede dar cuenta de la velocidad de transmisión de tu conexión, lo que aparentemente tu contratas como ancho de banda. Debido a la sesión intermitente la transmisión solo se realizaba en ocasiones como se puede ver en el siguiente gráfico:

Hubo ocasiones en que la transmisión era buena, pero en otra era pobre y en ocasiones nula.

Actividad #3 Lab: Coberturas de WiFi

Para esta entrada la actividad era monitorear la cobertura de las señales wifi disponibles en un punto "público", yo lo realice cerca de mi casa, donde había una buena cantidad de señales wifi.

Utilicé un dispositivo móvil con android para poder checar mejor la cobertura de las señales y poder tener un aproximado de su ubicación para poder dibujarlos en un mapa de google.

En el dispositivo móvil me apoye de una app llamada Wifi Analyzer que ayuda a mostrando la intensidad y la calidad de las redes wifi, además de otra información como el canal en que se difunde la señal, tipo de seguridad, etc. Si a alguien le interesa la app, aquí dejo el link a google play: Wifi Analyzer.

Aquí dejo unas capturas de la app funcionando, donde se muestra las intensidades de las distintas redes e información como la calidad, nombre, intensidad, etc.

intensidades de las señales disponibles

información más detallada de las redes disponibles

Y aquí una imagen del mapa de google con las coberturas de las redes dibujadas encima (con posiciones aproximadas):

Experimentos de Monitoreo WiFi

Lo que hice para esta entrada y para llevar a cabo una pequeña prueba con el wifi, fue un "ataque de des-autenticación" conocido como Ataque de Denegación de Servicios, que lo que hace des-autenticar  a un usuario en una red inyectando una gran cantidad de paquetes y con esto su conexión a internet se ve afectada dejándolo sin acceso a ninguna página.

Los pasos que seguí, son:

Primero conseguir una computadora con tarjeta wifi que soporte el cambio de operación de modo managed a modo monitor (batalle bastante en encontrar una compu compatible, en general las tarjetas intel no funcionan para esto, la que me funcionó fue una atheros que vienen en las netbooks acer).

Usando las herramientas de airmon, airodump y aireplay conseguí realizar todo, se pueden instalar en Ubuntu pero yo opté por usar otra distribución muy utilizada para auditorías y monitoreo wireless llamada Backtrack, que en sí es lo mismo solo que aquí ya vienen todas las herramientas necesarias. Y al igual que Ubuntu la puedes correr desde un usb, así lo hice yo porque la compu no era mía.

Para poner la tarjeta en modo monitor, ponemos en el terminal: airmon-ng start tarjetadwifi

Observamos las redes disponibles con : airodump-ng tarjeta_en_modo_monitor

Observamos el tráfico de la red que vamos a usar con:
airodump-ng --mac_punto_acceso  tarjeta_monitor

Identificamos a la víctima( su dirección mac).

Y procedemos a inyectar los paquetes para que dejarlo sin acceso a internet con:
aireplay-ng -0 0 -a mac_ap -c mac_víctima tarjeta_monitor

También podemos dejar sin acceso a internet a toda la red, esto solo incluyendo la mac del punto de acceso:

aireplay-ng -0 0 -a mac_ap tarjeta_monitor

Y por último los resultados en la compu que fue la víctima:

Al intentar acceder a las páginas solo se quedaban cargando pero nunca entraban y en ocasiones en el icono de conexión de red aparecía que la conectividad era nula.

Puse fotos de todo porque Backtrack me daba problemas al intentar sacar una captura de pantalla, era algo relacionado con la interfaz gnome.
Para esto usé dos compus (la mía y una prestada que funcionara el modo monitor) y la red wifi de mi casa.

_________________________________________________________________________________

Enlaces:

http://foro.elhacker.net/wireless_en_linux/guia_completa_aircrackng-t231434.0.html

http://www.backtrack-linux.org/

Actividad 2 - Infographic (conexión alámbrica)

Protocolos

La idea era crear un protocolo de transmisión de datos que funcionara en algún lado.

El protocolo que yo trate de establecer es sencillo y se puede orientar su uso en algún chat básico, muy básico.

Las reglas que manejé:

1. Al conectarse algún cliente, notificar su nombre de usuario al servidor.
2. El servidor debe de replicar el nombre de usuario a todos los clientes conectados.
3. Cuando algún cliente mande un mensaje, el servidor lo debe de replicar a todos los demás clientes y dejar claro quien lo esta enviando.
4. Cuando algún cliente se desconecte, el servidor debe de notificarlo a los demás clientes indicando quien se desconecto.

Una captura del programa/s donde se ejecutan estas acciones:

El código, para el servidor:

El código para el cliente:

Actividad #1 Laboratorio - Estándares

               USB 3.0           vs             Thunderbolt

 

  

Hace poco tiempo hubo una pequeña disputa por establecer cual estándar de estos dos posibles, reemplazaría al ya conocido USB 2.0. Este sustituto debería de reemplazar totalmente al anterior USB 2.0 en todos sus aspectos y debería de ser capaz de mejorarlos inclusive ofrecer nuevas opciones.

Cada uno defendía sus características (mas adelante las menciono), pero las mas importantes que tenían eran que los USB 3.0 físicamente son iguales a los USB 2.0 por lo que ofrecen retro-compatibilidad sin modificar nada (con la restricción de las limitaciones del USB 2.0) y los Thunderbolt físicamente son iguales a los puertos display-port, pero no ofrecen retro-compatibilidad con puertos que no esten preparados con esta nueva tecnología.

Características USB 3.0 (en cuanto a transferencias de datos)
Es la segunda revisión que se le hace a este periferico, diseñada en el 2008:

• En la primera versión(USB 1.0) las velocidades iban de 1.5Mbits/s hasta 12Mbits.
• En la segunda versión(USB 2.0) las velocidades se actualizaron e introdujeron un nuevo sistema llamado Hi-Speed que alcanzaba los 480Mbits/s.
• En la tercera versión se actulizaron otra vez las velocidades con nuevo sistema llamado Super-Speed y ahora alcanzan los 5Gbits/s.

Características Thunderbolt (transferencias de datos)
Fue lanzado en Febrero del 2011, principalmente en computadoras de Apple, ya que es más común el puerto display-port en estas computadoras.

Su velocidad de transmisión máxima es de 10Gbits/s, el doble del estandar USB 3.0 donde aparentemente le lleva ventaja.

Comparaciones y Conclusiones
El detalle está en sus velocidades de transmisión de datos, ya que los dos hacen prácticamente las mismas cosas.
Aparentemente en este apartado el Thunderbolt tendría la ventaja, pero debido a que su implementación generalmente solo es en computadoras Apple su mercado se reduce.

El USB 3.0 aún con menos velocidad de transferencia, su mercado puede ser más grande debido a que puede implementarse en cualquier computadora o dispositivo. Además del plus del poder contar la opción de seguir utilizando tus conexiones USB 2.0.

En un artículo que hace tiempo leí (no recuerdo su nombre ni donde fue) decía que el USB 3.0 originalmente no se llamaría así, si no que usaría otro nombre raro, pero que se declinó esta idea debido a que sería más factible para el usuario final relacionarlo con USB 2.0 y sus funcionalidades. Además de que lo verían como una actualización y no como un nuevo dispositivo.

En conclusión, actualmente el USB 3.0 sigue ganando terreno al Thunderbolt que yo personalmente solo lo he visto en computadoras Apple, la retro-compatibilidad con USB 2.0 ayuda mucho ya que no tenemos que deshacernos de nuestros dispositivos con este estándar en caso de hacernos de esta nueva tecnología o comprar nuevos dispositivos.
Yo creó que al final Thunderbolt es una buena opción pero desaparecerá.

Las empresas deberían de trabajar más en conjunto y no tanto individualmente como lo vienen haciendo para mejor este tipo de cosas. Se podría crear un apartado en la comisión que regula este tipo de cosas que cancele o anule la incursión de nuevos dispositivos/perifericos que se asemejen a alguno ya existente.

_________________________________________________________________________________

Referencias:

http://en.wikipedia.org/wiki/USB_3.0

http://en.wikipedia.org/wiki/Thunderbolt_(interface)

RFC 6127 - IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios

El RFC que elegí, habla de la coexistencia sin conflictos de los protocolos IPv4 e IPv6. Aquí dejo el link del documento que use como referencia: RFC 6127

Aparentemente esta cosa fue escrita con el fin de no batallar en un futuro (se creó en Octubre 2008) con el uso de los dos estandares (IPv4 e IPv6) par que estos pudieran trabajar conjuntamente sin fallas y que un futuro más lejano la versión IPv6 se quedara trabajando sola.

La idea es hacer que trabajen los dos en conjunto y que poco a poco la versión IPv6 valla desplazando a la IPv4 y que esto no sea un esto un gran problema......

Según el documento, cuando se diseño la IPv6 se hizo con el propósito de que soportara trabajar en redes y nodos donde se estuviera ejecutando IPv4, este método es conocido como "dual-stack [RFC 4213]" y es el mismo que se ha estado usando para desarrollar y proveer especificaciones y herramientas para este propósito hasta la actualidad.

Con el tiempo, se ha demostrado que la implementación del estándar IPv6 lleva tiempo y no esta siendo tan rápido como se pensaba, y si a esto se le agrega que el conjunto de direcciones IPv4 esta casi agotado, los ISP´s están ocupados buscando nuevos de diseños en sus redes que permitan la incursión de ambos estándares.

En el documento, se menciona que el método dual-stack es el mas usado para la interoperacion entre los dos estándares, pero no es el único ya que también se estan provando otros con el fin de facilitar todas estas actividades, relacionados con modelos multicapa para la traducción de direcciones IPv4 u otros asociados con la traducción de direcciones entre IPv4 e IPv6.

Según yo, estos métodos nuevo que se están probando pueden ayudar en mucho a la transición de IPv4 al IPv6, ya que permite la comunicación entre ambos y el desplazo poco a poco de la versión más antigua sin la necesidad de la desaparición total del IPv4, que no falta mucho para que suceda.

Se mencionan también algunos escenarios en donde se pueden aplicar lo que se busca con este documento:

• Crear una red de un tamaño muy grande que necesite muchas más direcciones de las que están disponibles en el espacio de direcciones privadas [RFC 1918].
• Crear una red donde se manejen únicamente direcciones IPv6 por facilidad de manejo en comparación de una donde se manejen los dos tipos de direcciones, pero que se siga necesitando acceso al Internet IPv4 para solamente un usuario.
• Tener acceso a un servidor con direcciones privadas IPv4 privadas por medio de direcciones IPv6.
• Accesar a servidores con direcciones IPv6 por medio de clientes IPv4.

En todos los casos se necesita la manipulación de los dos tipos de direcciones y su correcta convivencia, por lo que es necesario el surgimiento de métodos que permitan el manejo de estas situaciones al menos hasta que se desplace totalmente al IPv4.

En el aspecto de seguridad para estas situaciones destacan la importancia de la traducción de las direcciones de un estándar a otro y viceversa, ya que pueden impactar direcctamente con las NAT´s, DNS o Tunneling.

Por dar un ejemplo del impacto de esto en los servidores de DNS, una mala traducción de una dirección hacia el otro estándar podría hacer que al tratar de acceder a una página web la mala traducción de las direcciones enviara a otra página web al usuario.

Conclusión

En conclusión, la transición del mundo hacia el IPv6 continuará siendo lenta ya que cada vez se usan más y más dispositivos que ocupan una dirección ip y que al no estar totalmente establecido el IPv6 se recurre al uso del IPv4 y que posteriormente esta dirección necesitará reemplazo por una del IPv6. Todo esto hace ver que la implementación del IPv6 no esta siendo como se pensaba y que se requerirá de un mayor tiempo, además que se requiere el surgimiento de nuevos métodos para controlar y manipular la convivencia de los dos estándares en situaciones concretas.

A manera de sugerencia, se podría establecer una regla para que todas las nuevas estancias relacionadas con Internet se agreguen al nuevo estandar IPv6 forzosamente, esto con el fin de acelerar el proceso de transición.

_________________________________________________________________________________

Referencias:

Documento RFC 6127

http://datatracker.ietf.org/doc/rfc6127