Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Módulo 8: Desarrollo de Aplicaciones.

Presentación del tema: "Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Módulo 8: Desarrollo de Aplicaciones."— Transcripción de la presentación:

1 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 1 Broadcasting y Multicasting Capítulo 6

2 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 2 Broadcasting: repartiendo un texto a varios clientes Hello BroadcastCliente BraodcastServer

3 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 3 El servidor: recibiendo a un cliente nuevo 4444 El cliente contacta al servidor al 4444

4 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 4 4444 El servidor: recibiendo a un cliente nuevo Se ubica un nuevo socket y el canal de salida se abre. Ellos están dispuestos en un arreglo.

5 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 5 The server: Broadcasting a message When a message is entered the server will distribute it to the connected clients BroadcastCliente BraodcastServerNF Type a message

6 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 6 ¿ Cómo extenderlo para hacer un chat ? Hello

7 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 7 Condiciones para implementar un chat  El servidor debe estar atento a clientes que se quieren registrar en el chateo asi como a los mensajes que vienen de clientes ya conectados.  Cliente debe estar oyendo los mensajes del servidor y atendiendo a ver si el usuario escribe algo, lo cual debe mandar al servidor  Esto implica, necesitamos 2 hilos de ejecución paralelos en el servidor y otrs dos en el cliente  Tanto servidor como cliente son cliente y servidor a la vez (Ver CiCChat.java )

8 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 8 Comunicación Servidor-Cliente sin conexión  Hasta ahora hemos visto cómo se logran comunicar 2 programas estableciendo entre ellos un circuito virtual a través de una conexión TCP/IP.  Sabemos que en una conexión de este tipo se genera mucho tráfico y que la comunicación es más lenta, ya que el protocolo subyacente de confirmación, retransmisión, descarte y/o reordenación de paquetes se basa en mensajes de datagramas.  Habíamos visto que a veces el usuario debería optar por una transmisión sin conexión, especialmente si no es necesario garantizar la llegada de todos los datagramas.  Para eso existen en JAVA todos lor recursos de modo de mandar un datagrama aislado a un destinatario dado.

9 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 9 Manejo de Datagramas en JAVA  La comunicación se basa en armar paquetes UDP y enviarlos a la internet con la siguiente información:  Datos: un arreglo de bytes  Número de port del destinatario: int  Dirección Internet del destinatario: InetAddress  El servidor se pone a escuchar en un socket dado si hay paquetes destinados a él.  El cliente arma un paquete y lo lanza a la internet.  El servidor recibe el paquete y extrae los datos, número de port y dirección internet del enviador.  Si necesita responder manda un paquete a la dirección (port y dirección internet) que venía en el paquete recibido

10 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 10 UDP: comunicación con datagramas DATAGRAMA: un mensaje independiente, autocontenido, enviado a través de la internet internet, cuya llegada, tiempo de llegada y contenido no están garantizados (como el cooreo regular en algunos países....) Una vez que un servidor está escuchando, el cliente podría crear un datagrama con la dirección del servidor, número de puerto y el mensaje. A SERVER A CLIENT 4444 www.waseda1.jp message 4444 www.waseda2.jp ?

11 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 11 Mandando datagramas con protocolo UDP Luego éste podría abrir un socket y enviar el datagrama a la internet. El “algoritmo de enrutamiento” encontrará el camino al computador blanco. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ?

12 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 12 Antes que el datagrama abandone al cliente, éste recibe la dirección del computador de origen y el número de socket. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ! Mandando datagramas con protocolo UDP

13 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 13 Luego de que el datagrama es enviado, el computador del cliente puede empezar a escuchar en el puerto creado para enviar el datagrama si es que se espera una respuesta del servidor. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ? Mandando datagramas con protocolo UDP

14 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 14 El servidor puede extraer la dirección del cliente y el número del puerto para crear otro datagrama con la respuesta. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp answer ? Mandando datagramas con protocolo UDP

15 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 15 Finalmente el datagrama es enviado con la respuesta al “cliente”. Cuando un datagrama es enviado no hay garantía de que llegará al su destino. Si se desea comunicación confiable, debera proveerse de un mecanismo de chequeo, o usar... A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ? TiroPaquetes ReciboPaquetes Mandando datagramas con protocolo UDP

16 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 16 Clases para Datagramas en JAVA: envío  Definición: Un datagrama es un mensaje independiente, autocontenido que se manda de un programa a otro por la red pero que su llegada, tiempo de llegada y contenido no estan garantizados.  Crear un socket por donde mandar el datagrama  DatagramSocket ds = new DatagramSocket();  Crear y armar el datagrama  byte[] datos = new byte[256];  InetAddress direccion = InetAddress.getByName(“www.ctc.cl”);  DatagramPacket paquete = new DatagramPacket(datos, datos.length,direccion,4444);  Mandarlo  ds.send(paquete);  Esperar respuesta  socket.receive(packet); //limpiarlo antes !!!

17 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 17 Clases para Datagramas en JAVA: recepción  Para poder recibir tengo que escuchar en un port acordado (ya que de otra manera no hay cómo ponerse de acuerdo)  socket = new DatagramSocket(4444);  Preparar un Datagrama para recibir datos  byte[] datos = new byte[256];  DatagramPacket paquete = new DatagramPacket(datos,datos.length);  Ponerse a escuchar si alguien manda un datagrama a este computador a este port  socket.receive(paquete);  Sacar los datos, el port y la dirección de donde venía  int port = paquete.getPort();  InetAddress dirección = paquete getAddress();  String contenido = new String(paquete.getData());  Mandar una respuesta  DatagramPacket respuesta = new DatagramPacket(datos, datos.length, port, direccion);

18 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 18 El Reloj Remoto Un servidor reloj remoto estará poniendo al día el reloj con los paquetes UDP Servidor reloj remoto UDPClockClient.java UDPClockServer.java

19 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 19 El Servidor Reloj Remoto Múltiple UDPClockServerThread.java UDPClockMServer.java Un servidor reloj remoto estará poniendo al día el reloj con los paquetes UDP

20 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 20 ¿ Qué hay de la pérdida de paquetes ?  Datagramas UDP pueden perderse como los paquetes de internet  Podemos ver esto numerando los paquetes  Hagamos experimentos:  package loss entre Chile and Germany  package loss entre Japan and Chile  package loss entre Chile and Japan  Lo mismo para una red local:  con un número variable de clientes Tiro/ReciboPaquetesNoEnd

21 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 21 Un cliente Ping UDP  Usaremos el servidor de echo  en una máquina unix el servidor de echo está oyendo en el port 7 para UDP y para TCP  No es el mismo programa servidor sino que hay 2 sockets amarrados al mismo port !pero con diferente protocolo  El cliente ping va a mandar un paquete al servidor con la hora en que se mandó y el servidor lo enviará de vuelta  Comparando la hora en el datagrama y la actual podemos ver cuánto se demoró el viaje en redondo  El programa también calculará el max/min y med Ping.java

22 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 22 Multicasting  Qué pasa cuando se quiere hacer un broadcasting de datos demasiado pesados ?  Por cada cliente, el servidor queda mucho rato “pegado” escribiendo datos.  Imáginémonos ahora la situación en una videoconferencia: se trata de transmitir varios frames de video por segundo a una cantidad grande de “oyentes” => no es posible en la práctica!  En el Multicasting se trata de transmitir una sola vez la información a un punto en la internet, y desde ahí la leen los clientes.  Esto implica que el hardware (el de la red, se entiende) debe ser “multicastingable”

23 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 23 El Paradigma del Multicast PROG1 PROG2

24 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 24 Multicast & Broadcast  Multicast & Broadcast son protocolos que permiten a una aplicación poner un paquete único en la red el cual será recibido por varias aplicaciones  Broadcast trabaja sólo dentro de la red local. Un paquete mandado por broadcast lo recibirán todos.  Requiere soporte de hardware de la red local.  Un paquete de multicast sólo lo recibirán los programas que se registraron para ello previamente  Multicast requiere apoyo en el host y los routers

25 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 25 Multicast  Multicast en Java es similar a UDP excepto que el envío-recibo de paquetes debe ser implementado para una dirección IP en el rango (224.0.0.0 - 239.255.255)  Para poder recibir paquetes de multicast el cliente debe haber previamente haber expresado su interes en unirse a un grupo multicast identificado por una direccion IP multicast y un port.  La red (es decir los ruteadores) se encargarán de transmitir los paquetes a todas las aplicaciones interesadas en la internet (teóricamente!)  Cualquier aplicación puede mandar paquetes al grupo !

26 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 26 Qué pasa cuando se lanza un paquete  El paquete será tomado por todas las máquinas de la red local interesadas.  Además, los ruteadores tomarán el paquete y lo mandarán a las redes vecinas si hay una aplicación interesada  El determinar si hay una aplicación interesada en las redes adyacentes añade una complejidad significativa al algoritmo de ruteo  El problema es cómo va a saber el ruteador si una vecina a la vecina está interesada  Esto requiere el almacenaje de mayor información en las tablas de ruteo

27 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 27 Comunicación de Grupo con Multicast Provee: Tolerancia a fallas basada en la replicidad de servicios: un servicio replicado consiste en un grupo de servidores. El cliente manda el request a todos los servidores que realizan la misma operación. Encuentro de servicios de descubrimiento de servidores: clientes y servidores usan mensajes de multicast para localizar servicios presentes en la red para poder registrar sus interfaces y y hacer lookup de interfaces de otros servicios Mejor performance por datos replicados: a veces se replican los datos en los computadores cliente (cache) cuando estos varían el servidor manda mensajes por multicast Propagación de eventos de notificación: para notificar a procesos interesados en ciertos eventos que estos tuvieron lugar (jini)

28 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 28 Fallas en Multicast Ya que se basa en UDP puede pasar : Tolerancia a fallas basada en la replicación de servicios: Si los servidores parten de un mismo estado inicial y se coordinan con los updates en un orden preciso. Si un miembro no recibe el update o lo recibe en mal orden se vuelve inconsistente Encuentro de servicios de descubrimiento de servidores: esto no es problema si las peticiones de localización se hacen reiterativamente en tiempos regulares. Así se hace en Jini Mejor performance por datos replicados: si en vez de replicar operaciones en los datos lo que se replica es el dato mismo, estos pueden aparecer inconsistentemente en cada servidor Propagación de eventos de notificación: El servicio de anuncio acerca de nuevos servicios en la red provisto por Jini envía mensajes multicast reiterativos a tiempos regulares

29 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 29 import java.io.*; import java.net.*; public class MulticastClient { public static void main(String[] args) throws IOException { MulticastSocket socket = new MulticastSocket(4446); InetAddress address = InetAddress.getByName("224.2.2.3"); socket.joinGroup(address); byte[] buf = new byte[256]; DatagramPacket packet; while(true) { packet = new DatagramPacket(buf, buf.length); socket.receive(packet); String received = new String(packet.getData()); System.out.println("Received: " + received); try { Thread.currentThread().sleep(0); } catch (InterruptedException e) { } Ejemplo de Multicast en Java import java.io.*; import java.net.*; import java.util.*; public class MulticastServer { static public void main(String args[]) { DatagramSocket socket = null; BufferedReader in = null; boolean moreQuotes = true; try { socket = new DatagramSocket(); while (true) { InetAddress grupo = InetAddress.getByName("224.2.2.3"); for (int i=1; i< 1000; i++) { String dString = i+"--"+(InetAddress.getLocalHost()); byte[] buf = dString.getBytes(); DatagramPacket packet = new DatagramPacket(buf, buf.length, grupo, 4446); socket.send(packet); try { Thread.currentThread().sleep(200); } catch (InterruptedException e) {} } } catch (IOException e) {} }

30 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 30 Apoyo de Java para Multicast  MulticastSocket: extensión de DatagramSocket  MulticastSocket( ) se amarra a cualquier port libre  MulticastSocket(int port) usa port específico  Muchos socekts multicast pueden ser amarrados al mismoport! (no como en TCP o UDP)  Métodos heredados (send, receive) + 3 nuevos  joinGroup(InetAddress group)  leaveGroup(InetAddress group)  setTimeToLive(int ttl)

31 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 31 Un Chat basado en Multicast  No hay servidor.  Cada participante corre el mismo programa uniéndose al grupo multicast Los mensajes salen como datagramas “multicast” a la red, por lo cual cualquier aplicación interesada lo recibirá No hay garantía de si llegará, en cuanto rato, en qué órden ni si se duplicarán ! MulticastChat

32 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 32 Modelo de Multicast para grupos Multicast tiene cualidades que lo hacen más eficiente para transmitir un mensaje a varios miembros de un grupo Modelo: message(g,m) : operación de transmisión de un mensaje m a los miembros de un grupo g deliver(m) : operación de proceso de mensaje m sender(m) : identificación del que manda el mensaje group(m) : grupo de destino del mensaje open/closed group : el grupo puede/no puede recibir mensajes mandados por un por un miembro que no pertenece al grupo

33 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 33 Reliable Multicast Reliable multicast implica que se cumplen 3 propiedades: Integridad: el mensaje que se manda es igual al que se procesa y que ningún mensaje es procesado dos veces. Un proceso p hace la operación deliver(m) una sola vez y p  group(m) Validez : si un proceso manda un mensaje multicast, tarde o temprano él también lo procesará si pertenece al grupo Agreement : si un proceso procesa un mensaje m el resto de los miembros del grupo también lo hará

34 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 34 Reliable Multicast con IP ! Cada proceso p mantiene un número de secuencia S(p,g) para cada grupo g al que pertenece. También mantiene un registro R(q,g) que es el número de secuencia del último mensaje procesado del proceso q que mandó al grupo g. Cuando p quiere mandar un mensaje a g incluye el número S(p,g) y pares, luego incrementa S(p,g). Un proceso del grupo procesa el mensaje mandado por p sólo si el S = R(p,g) +1 Si S <= R(p,g) es un mensaje repetido y lo descarta Si S > R(p,g) + 1 significa que perdió un mensaje y manda un ack negativo para que lo mande de nuevo. Integridad se alcanza por la detección de duplicados y los checkeos de IP en los datagramas. Validez por propiedad de IP. Agreement implica que los procesos siempre guardan copias de mensajes enviados para enviarlos de nuevo para que esto funcione los proceso no deben fallar !!!!

35 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 35 Ordenando los mensajes de Multicast Se usa un cola de mensajes multicast para guardarlos antes de procesarlos. Se trata de asignar un número de secuencia para cada mensaje en el cual todos estén de acuerdo. Cada proceso q en un grupo g mantiene un número A(q,g), el más grande de la secuencia acordada que se ha observado para un grupo g y P(q,g) el mayor de la secuencia propia. Cuando p quiere mandar un mensaje: Manda en forma segura siendo m el mensaje e i un identificador único para m cada proceso q responde a p con una proposición para acordar un número de secuencia para ese mensaje P(q,g) = Max(A(q,g), P(q,g))+1. Cada proceso guarda en su cola el mensaje con el número de secuencia que propuso provisionalmente ordenado de menor a mayor número de secuencia p recolecta todos los números de secuencia propuestos y selecciona el mayor a como el que se usará definitivamente y lo transmite en un mensaje broadcast seguro cada proceso entonces ordena la cola de mensajes antes de procesarlos según los números de secuencia acordados ¿ Cómo se puede demostrar que esto es monotonicamente creciente ?

36 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 36 Time to Live  Los paquetes multicast incluyen (como todos los paquetes de internet) un campo TTL que en este caso adquiere la importancia de evitar que se propague demasiado por la internet  Por esto también es posible en java definir el TTL que saldrán de un socket dado.

37 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 37 MBone  Multicast no está muy difundida en la internet. Esto es por un lado porque se genera muho tráfico y, por el otro, la ausencia de ruteadores con el protocolo IGMP  Hay una subred llamada MBone que comunica islas de redes multicas permitiéndo que los paquetes multicast viajen entre ellas a través de túneles.  Un tunel omunica los routers de dos redes que no están físicamente adjacentes.  Los paquetes serán pasados de una red a otra como si estuvieran conectados físicamentes

38 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 38 Broadcast  Broadcast es similar a Multicast pero en una red local  Cada red basada en broadcast (como ethernet) tiene una dirección de broadcast IP. Cualquier mensaje mandado a esta dirección será recibido por todos los coputadores de esa red.  Usualmente esta es la última dirección IP de la subred:  Clase C: 192.1.2.0 -> 192.1.2.255  Para una subred de 16 hosts 197.84.66.192 -> 197.84.66.207  Se debe en todo caso especificar el número de port UDPBroadcastClient/Server

39 Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2001 Módulo 8: Desarrollo de Aplicaciones en Redes 39 ¿ Broadcast o Multicast ?  Si se puede elegir es mejor usar multicast porque moleta sólo a las máquinas interesadas.  A veces es necesario tener privilegios sobre la red para usar la direccion multicast.  Multicast permite definir varios grupos dentro de la misma red  El tráfico generado es el mismo: se pone un paquete en la red pero todos lo leerán  Broadcast no tiene absolutamente ningúna diferencia con UDP en Java. Sólo la dirección IP es especial