Simuladores de Redes

Primero que es ns?

Es un simulador de redes basado en eventos discretos.

Se usa principalmente en ambientes educativos y de investigación. Permite simular tanto protocolos unicast como multicast y se utiliza intensamente en la investigación de redes móviles ad-hoc. Implementa una amplia gama de protocolos tanto de redes cableadas como de redes inalámbricas. La versión actual, ns-3, esta diseñada para soportar todo el flujo de trabajo de la simulación desde la configuración hasta la recolección y análisis de tramas.

ns es software libre, se ofrece bajo la versión 2 de la GNU General Public License. Cuenta con dos versiones ns-2 y ns-3 que en general son incompatibles.

Básicamente todo el texto se refiere a que:

Se evalúan algunas características para garantizar calidad de servicio como el ancho de banda y la pérdida de paquetes.

En la calidad de servicio existen dos tipos de tecnologías de QoS asociadas hasta cierto punto directamente con IP.
 La primera de ellas denominada servicios diferenciados, se caracteriza por marcar los paquetes de acuerdo a su prioridad, mientras que la segunda tecnología, denominada servicios integrados, se basa en reserva y asignación de recursos dependiendo del tipo de tráfico

Sobre una topología de red que involucra tres tipos de tráfico (CBR, Pareto y Exponencial). 

Se implementan cinco configuraciones diferentes en el simulador de redes NS2, donde el primero corresponde a un caso sin QoS, con una capacidad de canal que es suficientemente grande para trasmitir los tres tipos de tráfico, mientras que en las siguientes cuatro configuraciones la capacidad se reduce a un menor tamaño y se estudian diferentes casos de calidad de servicio.

Para observar el comportamiento de los tráficos se implementa inicialmente una red sin QoS con dos tipos de encolamiento y posteriormente se realiza una configuración que implementa QoS mediante los modelos IntServ y DiffServ.

Los resultados obtenidos de estas simulaciones son graficados y comparados con el fin de determinar el comportamiento más adecuado en redes IP.

En fin esta es una revisión sobre los principales simuladores de red y la importancia de estos para los procesos de investigación y desarrollo de las telecomunicaciones así como de la efectividad de los mismos para recrear de manera suficientemente aproximada los procesos que se realizan en las redes reales ya que con el uso de estas herramientas se están analizando y probando los nuevos protocolos de red, siendo de gran importancia poder contar con resultados confiables generados a partir de procesos de simulación.

--

Lo importante al momento de implementar una topología deben tenerse en cuentas diversos aspectos, muchos de los cuales fueron mencionados durante la evaluación de cada modelo. Aspectos como el retardo, la latencia o jitter, las pérdidas

Sin embargo existe un aspecto no mencionado pero fundamental a tener en cuenta y es la 

aplicación que esta red tendrá. Deben conocerse muy bien los tráficos que se trabajarán con 

el fin de establecer si se requiere una red con pérdidas equitativas para cada fuente de transmisión, o si solo algunas de las fuentes son importantes.

Surge entonces la necesidad de seleccionar alguno de los dos modelos. El modelo IntServ 

aunque garantiza el ancho de banda para el tipo de tráfico seleccionado, deja los tráficos 

restantes sin QoS, causando que luchen entre ellos para poder enviar sus paquetes, a diferencia del modelo DiffServ, el cual asigna un tipo de prioridad a cada tipo te tráfico otorgando así una calidad de servicio diferente a cada uno, por ello, con DiffServ se pierde mucha información de un tipo de datos si estos tienen asignado el valor más bajo de prioridad y si el canal se encuentra saturado por mucho tiempo.

Experimentos de Calidad de Servicio

QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen servicio. Es especialmente importante para ciertas aplicaciones tales como la transmisión de vídeo o voz

Problemas en redes de datos conmutados

Muchas cosas le ocurren a los paquetes desde su origen al destino, resultando los siguientes problemas vistos desde el punto de vista del transmisor y receptor:Paquetes sueltos

los ruteadores pueden fallar en liberar algunos paquetes si ellos llegan cuando los buffers ya están llenos. Algunos, ninguno o todos los paquetes pueden quedar sueltos dependiendo del estado de la red, y es imposible determinar que pasará de antemano. La aplicación del receptor puede preguntar por la información que será retransmitida posiblemente causando largos retardos a lo largo de la transmisión.Retardos

puede ocurrir que los paquetes tomen un largo período en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congestión de la red. En algunos casos, los retardos excesivos pueden inutilizar aplicaciones tales como VoIP o juegos en línea.Jitter

los paquetes del transmisor pueden llegar a su destino con diferentes retardos. Un retardo de un paquete varía impredeciblemente con su posición en las colas de los ruteadores a lo largo del camino entre el transmisor y el destino. Esta variación en retardo se conoce como jitter y puede afectar seriamente la calidad del flujo de audio y/o vídeo.Entrega de paquetes fuera de orden

cuando un conjunto de paquetes relacionados entre sí son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de como fueron enviados. Este problema requiere un protocolo que pueda arreglar los paquetes fuera de orden a un estado isócrono una vez que ellos lleguen a su destino. Esto es especialmente importante para flujos de datos de vídeo y VoIP donde la calidad es dramáticamente afectada tanto por latencia y pérdida de sincronía.Errores

A veces, los paquetes son mal dirigidos, combinados entre sí o corrompidos cuando se encaminan. El receptor tiene que detectarlos y justo cuando el paquete es liberado, pregunta al transmisor para repetirlo así mismo.

Primero 

el test se realizo con las siguientes velocidades

Telcel 3G/E

Telmex infinitum

las pruebas se realizaron en un xbox360/wifi

Telcel 3G/E

Prueba Infinitum

Se realizaron con la misma calidad

La perdida de paquetes es muy baja
para forzar la perdida de paquetes se conectaron varias pc a la red y empezamos a descargar cosas
en este caso si empezó a ver mas notable la baja velocidad del vídeo he incremento de perdida de paquetes pero seguía siendo muy poco porcentaje

Experimentos de monitoreo

Experimentos de monitoreo

En esta ocacion se intento monitorear la pagina del s... la escuela
El monitoreo se realizo con un programa para "Hackear/ modificar juegos en linea"
Cheat engine
el cual se puede utilizar para diversas paginas ya que el programa no trabaja para un juego en especifico
yo realice las pruebas en juegos como el diamon dash de facebook y se aceleraba el tiempo
también puede acelerar descargas como lo veremos en el siguiente vídeo


..

básicamente el programa toma todos los cambios de la pagina y puedes buscar los valores para no estar checando todas las direcciones

El video realizado
esta subiéndose ya que se tuvo algunos problemas con el grabado y la computadora :P

Implementación De Un Protocolo

En los sockets TCP es necesario establecer una conexión. El servidor TCP espera que un cliente TCP se le conecte. Una vez hecha la conexión, se pueden enviar mensajes. El protocolo TCP garantiza que todos los mensajes enviados van a llegar bien y en el orden enviado. Sólo el cliente necesita saber dónde está el servidor y en qué puerto está escuchando.

Por el contrario, en los sockets UDP no se establece conexión. El servidor se pone a la escucha de un puerto de su ordenador. El cliente también se pone a la escucha de un puerto de su ordenador. En cualquier momento, cualquiera de ellos puede enviar un mensaje al otro. Ambos necesitan saber en qué ordenado y en qué puerto está escuchando el otro. Aquí el concepto de cliente y servidor está un poco más difuso que en el caso de TCP. Podemos considerar servidor al que espera un mensaje y responde. Cliente sería el que inicia el trasiego de mensajes. El servidor debería, además, estar siempre arrancado y a la escucha.

Además, en contra de TCP, el protocolo UDP sólo garantiza que si el mensaje llega, llega bien. No garantiza que llegue ni que lleguen en el mismo orden que se han enviado. Este tipo de sockets es útil para el envío más o menos masivo de información no crucial. Por ejemplo, enviar los datos para el refresco de gráficos en una pantalla.

Otra ventaja de UDP respecto a TCP, es que con UDP se puede enviar un mensaje a varios receptores a la vez, mientras que en TCP, al haber una conexión previa, sólo se puede enviar el mensaje al que está conectado al otro lado. Con UDP se puede, por ejemplo, enviar una sola vez los datos para que varias pantallas refresquen sus gráficos a la vez.


LA CLASE DatagramSocket

Tanto cliente como servidor, para ponerse a la escucha de un puerto UDP, únicamente tienen que instanciar la clase DatagramSocket, pasándole los parámetros adecuados:
El número de puerto que están escuchando.
El InetAddress del ordenador en que se está corriendo cada uno, habitualmente InetAddress.getLocalHost();

Por ello, el código del servidor es tan sencillo como esto
ServidorUdp.java
DatagramSocket socket = new DatagramSocket(
           Constantes.PUERTO_DEL_SERVIDOR,
           InetAddress.getByName("localhost"));

y el del cliente se parece bastante

ClienteUdp.java
DatagramSocket socket = new DatagramSocket(
         Constantes.PUERTO_DEL_CLIENTE,
          InetAddress.getByName("localhost"));

LA CLASE DatagramParcket

Esta es la clase que se va a enviar y recibir como mensaje. Lleva dentro un array de bytes que es el que debemos rellenar con lo queremos enviar o en el que estará lo que hemos recibido.

Dependiendo de si es para enviar o recibir, esta clase se instancia de forma distinta. En ambos casos hay que pasarle el array de bytes. En el caso de enviar, hay que pasarle además la InetAdress del destinatario y el puerto en el que está escuchando el destinatario.

Para enviar

DatagramPacket dato = new DatagramPacket(

   elDatoEnBytes, // El array de bytes

   elDatoEnBytes.length, // Su longitud

   InetAddress.getByName(Constantes.HOST_SERVIDOR),  // Destinatario

   Constantes.PUERTO_DEL_SERVIDOR);   // Puerto del destinatario

Para recibir

DatagramPacket dato = new DatagramPacket(new byte[100], 100);

ENVIAR Y RECIBIR LOS DatagramPacket
Para enviar el DatagramPacket, debemos llamar al método send() de DatagramSocket pasando como parámetro el DatagramPacket que acabamos de crear.
Enviar DatagramPacket
socket.send(dato);

Para recibir, igual pero con socket.receive().

Recibir DatagramPacket
socket.receive(dato);


CONVERTIR UNA CLASE Serializable A ARRAY DE BYTES Y VICEVERSA
Lo de meter un array de bytes en el DatagramPacket está muy bien si leemos bytes de un fichero o de algún otro sitio. Sin embargo, si queremos enviar o recibir clases (Serializable, por supuesto), tenemos que hacer una conversión. Los siguientes código nos ayudan a hacer este tipo de conversiones. Suponemos que la clase se llamaDatoUdp y que implenta la interface Serializable.

De Serializable a byte[]

ByteArrayOutputStream bytes = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream (bytes);
os.writeObject(this); // this es de tipo DatoUdp
os.close();
return bytes.toByteArray(); // devuelve byte[]

De byte[] a Serializable

ByteArrayInputStream byteArray = new ByteArrayInputStream(bytes); // bytes es el byte[]
ObjectInputStream is = new ObjectInputStream(byteArray);
DatoUdp aux = (DatoUdp)is.readObject();
is.close();
return aux;

EL EJEMPLO

Con todo esto ya sabemos lo necesario para hacer un pequeño ejemplo de Servidor udp y cliente udp

Constantes

/** Constantes para el ejemplo de envío y recepción con socket udp. */

public class Constantes

{

    /** Puerto en el que escucha el servidor. */

    public static final int PUERTO_DEL_SERVIDOR=5557;

   

    /** Puerto en el que escucha el cliente */

    public static final int PUERTO_DEL_CLIENTE=5558;

   

    /** Host en el que está el servidor */

    public static final String HOST_SERVIDOR="localhost";

   

    /** Host en el que está el cliente */

    public static final String HOST_CLIENTE="localhost";

Dato udp


import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class DatoUdp implements Serializable
{
    /**
     * serial uid
     */
    private static final long serialVersionUID = 3258698714674442547L;

    /**
     * Crea una instancia de la clase, guardando la cadena que se le pasa.
     * @param cadena
     */
    public DatoUdp (String cadena)
    {
        this.cadenaTexto=cadena;
    }
    public String cadenaTexto;
 
    /**
     * Se autoconvierte esta clase a array de bytes.
     * @return La clase convertida a array de bytes.
     */
    public byte [] toByteArray()
    {
        try
        {
             // Se hace la conversión usando un ByteArrayOutputStream y un
             // ObjetOutputStream.
            ByteArrayOutputStream bytes = new ByteArrayOutputStream();
            ObjectOutputStream os = new ObjectOutputStream (bytes);
            os.writeObject(this);
            os.close();
            return bytes.toByteArray();
        }
        catch(Exception e)
        {
            e.printStackTrace();
            return null;
        }
    }
 
    /**
     * Se convierte el array de bytes que recibe en un objeto DatoUdp.
     * @param bytes El array de bytes
     * @return Un DatoUdp.
     */
    public static DatoUdp fromByteArray (byte [] bytes)
    {
        try
        {
            // Se realiza la conversión usando un ByteArrayInputStream y un
            // ObjectInputStream
            ByteArrayInputStream byteArray = new ByteArrayInputStream(bytes);
            ObjectInputStream is = new ObjectInputStream(byteArray);
            DatoUdp aux = (DatoUdp)is.readObject();
            is.close();
            return aux;
        }
        catch(Exception e)
        {
            e.printStackTrace();
            return null;
        }
    }
}


Cliente

import java.net.DatagramPacket;

import java.net.DatagramSocket;

import java.net.InetAddress;

/**

 * Abre un socket udp y envía por él 10 mensajes consistentes en 10 clases

 *

 */

public class ClienteUdp

{

    /**

     * Programa de prueba. Instancia esta clase

     * @param args

     */

    public static void main(String[] args)

    {

        new ClienteUdp();

    }

    /**

     * Crea una instancia de esta clase y envía los 10 mensajes

     *

     */

    public ClienteUdp()

    {

        try

        {

            // La IP es la local, el puerto es en el que este cliente esté

            // escuchando.

            DatagramSocket socket = new DatagramSocket(

                    Constantes.PUERTO_DEL_CLIENTE, InetAddress

                            .getByName("localhost"));

            // Se instancia un DatoUdp y se convierte a bytes[]

            DatoUdp elDato = new DatoUdp("hola");

            byte[] elDatoEnBytes = elDato.toByteArray();

            // Se meten los bytes en el DatagramPacket, que es lo que se

            // va a enviar por el socket.

            // El destinatario es el servidor.

            // El puerto es por el que esté escuchando el servidor.

            DatagramPacket dato = new DatagramPacket(elDatoEnBytes,

                    elDatoEnBytes.length, InetAddress

                            .getByName(Constantes.HOST_SERVIDOR),

                    Constantes.PUERTO_DEL_SERVIDOR);

           

            // Se envía el DatagramPacket 10 veces, esperando 1 segundo entre

            // envío y envío.

            for (int i = 0; i < 10; i++)

            {

                System.out.println("Envio dato " + i);

                socket.send(dato);

                Thread.sleep(1000);

            }

        } catch (Exception e)

        {

            e.printStackTrace();

        }

    }
}

Servidor udp

import java.net.DatagramPacket;

import java.net.DatagramSocket;

import java.net.InetAddress;

/**

 * Servidor de udp que se pone a la escucha de DatagramPacket que contengan

 * dentro DatoUdp y los escribe en pantalla.

 */

public class ServidorUdp

{

    /**

     * Prueba del prorama ServidorUdp

     *

     * @param args

     */

    public static void main(String[] args)

    {

        new ServidorUdp();

    }

    /**

     * Crea una instancia de esta clase, poniendose a la escucha del puerto

     * definido en Constantes y escribe en pantalla todos los mensajes que le

     * lleguen.

     */

    public ServidorUdp()

    {

        try

        {

            // La IP es la local, el puerto es en el que el servidor esté

            // escuchando.

            DatagramSocket socket = new DatagramSocket(

                    Constantes.PUERTO_DEL_SERVIDOR, InetAddress

                            .getByName("localhost"));

            // Un DatagramPacket para recibir los mensajes.

            DatagramPacket dato = new DatagramPacket(new byte[100], 100);

            // Bucle infinito.

            while (true)

            {

                // Se recibe un dato y se escribe en pantalla.

                socket.receive(dato);

                System.out.print("Recibido dato de "

                        + dato.getAddress().getHostName() + " : ");

               

                // Conversion de los bytes a DatoUdp

                DatoUdp datoRecibido = DatoUdp.fromByteArray(dato.getData());

                System.out.println(datoRecibido.cadenaTexto);

            }

        } catch (Exception e)

        {

            e.printStackTrace();

        }

    }

}

Deberías ver cómo el cliente envía 10 mensajes y el servidor los escribe en pantalla. Si no ejecutas ambos programas en el mismo ordenador, tendrás que cambiar los fuentes para que el cliente tenga el nombre del servidor.

Protocolo RFC

SMTP Extension for Internationalized Email

RFC 6531

Extensión SMTP para el correo electrónico internacionalizados


Es un protocolo de la capa de aplicación. Protocolo de red basado en texto, utilizados para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos (PDA, teléfonos móviles, etc.)

La mayoría de los sistemas de correo electrónico que envían correo a través de Internet utilizan SMTP para enviar mensajes de un servidor a otro, los mensajes se pueden recuperar con un cliente de correo electrónico utilizando POP o IMAP . Además, SMTP es generalmente utilizado para enviar mensajes desde un cliente de correo a un servidor de correo. Por ello, es necesario especificar tanto el servidor POP o IMAP y el servidor SMTP cuando configure su dirección de e-mail solicitud .

SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje a uno o varios receptores.
La comunicación entre el cliente y el servidor consiste enteramente en líneas de texto compuestas por caracteres ASCII. El tamaño máximo permitido para estas líneas es de 1000 caracteres.
Las respuestas del servidor constan de un código numérico de tres dígitos, seguido de un texto explicativo. El número va dirigido a un procesado automático de la respuesta por autómata, mientras que el texto permite que un humano interprete la respuesta. En el protocolo SMTP todas las órdenes, réplicas o datos son líneas de texto, delimitadas por el carácter <CRLF>. Todas las réplicas tienen un código numérico al comienzo de la línea.
En el conjunto de protocolos TCP/IP, el SMTP va por encima del TCP, usando normalmente el puerto 25 en el servidor para establecer la conexión.


Resumen simple del funcionamiento del protocolo SMTP

· Cuando un cliente establece una conexión con el servidor SMTP, espera a que éste envíe un mensaje “220 Service ready” o “421 Service non available”
· Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conectó con el servidor SMTP correcto.
· El cliente comienza la transacción del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es válido, el servidor responde “250 OK”.
· Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestará “250 OK” o bien “550 No such user here”, si no encuentra al destinatario.· Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que a continuación se envían los contenidos del mensaje. El servidor responde “354 Start mail input, end with <CRLF>.<CRLF>” Esto indica al cliente como ha de notificar el fin del mensaje.
· Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se termina con un <CRLF>.<CRLF> (la última línea será un punto), a lo que el servidor contestará “250 OK”, o un mensaje de error apropiado.
· Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la conexión. También puede usar la orden TURN, con lo que el cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene más mensajes que enviar, repite el proceso hasta completarlos. Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestará con una lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestará con un mensaje "500 Syntax error, command unrecognized".


En el ejemplo pueden verse las órdenes básicas de SMTP:

· HELO, para abrir una sesión con el servidor
· MAIL FROM, para indicar quien envía el mensaje
· RCPT TO, para indicar el destinatario del mensaje
· DATA, para indicar el comienzo del mensaje, éste finalizará cuando haya una línea únicamente con un punto.
· QUIT, para cerrar la sesión
· RSET Aborta la transacción en curso y borra todos los registros.
· SEND Inicia una transacción en la cual el mensaje se entrega a una terminal.
· SOML El mensaje se entrega a un terminal o a un buzón.
· SAML El mensaje se entrega a un terminal y a un buzón.
· VRFY Solicita al servidor la verificación del argumento.
· EXPN Solicita al servidor la confirmación del argumento.
· HELP Permite solicitar información sobre un comando.
· NOOP Se emplea para reiniciar los temporizadores.
· TURN Solicita al servidor que intercambien los papeles.

De los tres dígitos del código numérico, el primero indica la categoría de la respuesta, estando definidas las siguientes categorías:

· 2XX, la operación solicitada mediante el comando anterior ha sido concluida con éxito
· 3XX, la orden ha sido aceptada, pero el servidor esta pendiente de que el cliente le envíe nuevos datos para terminar la operación
· 4XX, para una respuesta de error, pero se espera a que se repita la instrucción
· 5XX, para indicar una condición de error permanente, por lo que no debe repetirse la orden

Una vez que el servidor recibe el mensaje finalizado con un punto puede almacenarlo si es para un destinatario que pertenece a su dominio, o bien retransmitirlo a otro servidor para que finalmente llegue a un servidor del dominio del receptor.

Ejemplo de una comunicación SMTP

En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el receptor (servidor). Esto puede hacerse automáticamente con un programa cliente de correo o mediante un cliente telnet.

En el siguiente ejemplo se muestra una conexión típica. Se nombra con la letra C al cliente y con S al servidor.

S: 220 Servidor ESMTP
C: HELO miequipo.midominio.com
S: 250 Hello, please to meet you
C: MAIL FROM: <yo@midominio.com>
S: 250 Ok
C: RCPT TO: <destinatario@sudominio.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Campo de asunto
C: From: yo@midominio.com
C: To: destinatario@sudominio.com
C:
C: Hola,
C: Esto es una prueba.
C: Hasta luego.
C:
C: .
S: 250 Ok: queued as 12345
C: quit
S: 221 Bye

Formato del mensaje

Como se muestra en el ejemplo anterior, el mensaje es enviado por el cliente después de que éste manda la orden DATA al servidor. El mensaje está compuesto por dos partes:

· Cabecera: en el ejemplo las tres primeras líneas del mensaje son la cabecera. En ellas se usan unas palabras clave para definir los campos del mensaje. Estos campos ayudan a los clientes de correo a organizarlos y mostrarlos. Los más típicos son subject (asunto), from (emisor) y to (receptor). Éstos dos últimos campos no hay que confundirlos con las órdenes MAIL FROM y RCPT TO, que pertenecen al protocolo, pero no al formato del mensaje.

· Cuerpo del mensaje: es el mensaje propiamente dicho. En el SMTP básico está compuesto únicamente por texto, y finalizado con una línea en la que el único carácter es un punto.

Seguridad y Spam

Una de las limitaciones del SMTP original es que no facilita métodos de autenticación a los emisores, así que se definió la extensión SMTP-AUTH.