Broadcasting y Multicasting

1
BroadcastingyMulticasting

• Capítulo 6

2
Broadcasting repartiendo un texto a varios
clientes
3
El servidor recibiendo a un cliente nuevo
4444
El cliente contacta al servidor al 4444
4
El servidor recibiendo a un cliente nuevo
4444
Se ubica un nuevo socket y el canal de salida se
abre. Ellos están dispuestos en un arreglo.
5
The server Broadcasting a message
Type a message
When a message is entered the server will
distribute it to the connected clients
BraodcastServerNF
BroadcastCliente
6
Cómo extenderlo para hacer un chat ?
Hello
Hello
Hello
Hello
Hello
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
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
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
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.
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
?
4444
www.waseda1.jp
4444
message
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.
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
?
3333
4444
12
Mandando datagramas con protocolo UDP
Antes que el datagrama abandone al cliente, éste
recibe la dirección del computador de origen y el
número de socket.
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
!
3333
4444
13
Mandando datagramas con protocolo UDP
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.
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
?
3333
4444
14
Mandando datagramas con protocolo UDP
El servidor puede extraer la dirección del
cliente y el número del puerto para crear otro
datagrama con la respuesta.
www.waseda1.jp
www.waseda2.jp
A SERVER
A CLIENT
?
3333
4444
answer
15
Mandando datagramas con protocolo UDP
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...
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
?
3333
4444
TiroPaquetes
ReciboPaquetes
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 byte256
• 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
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 byte256
• 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(dato
  s, datos.length, port, direccion)

18
El Reloj Remoto
Servidor reloj remoto
UDPClockServer.java
Un servidor reloj remoto estará poniendo al día
el reloj con los paquetes UDP
UDPClockClient.java
19
El Servidor Reloj Remoto Múltiple
Un servidor reloj remoto estará poniendo al día
el reloj con los paquetes UDP
UDPClockServerThread.java
UDPClockMServer.java
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
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
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 gt 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
El Paradigma del Multicast
PROG2
PROG1
PROG2
PROG2
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
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
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
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
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
Ejemplo de Multicast en Java
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 byte256 DatagramPacket packet while(tru
e) 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)
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 i1 ilt 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
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
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
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
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
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 ltq,R(q,g)gt, 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 lt R(p,g) es un mensaje repetido y lo
  descarta
• Si S gt 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
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 ltm,igt 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 lti,agt
• 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
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
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
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 -gt 192.1.2.255
• Para una subred de 16 hosts 197.84.66.192 -gt
  197.84.66.207
• Se debe en todo caso especificar el número de
  port

UDPBroadcastClient/Server
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