Arquitecturas Cliente / Servidor

Arquitecturas Cliente / Servidor Sockets broadcas6ng y mul6cas6ng Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza 4. Sockets broadcas6ng y mul6cas6ng •  Broadcast. –  Definición de Broadcast. –  Funcionamiento Broadcast. –  Creación del socket Broadcast. •  Mul8cast. –  Definición de Mul8cast. –  Funcionamiento Mul8cast (IGMP). –  Creación del socket Mul8cast. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Introducción •  Hasta ahora hemos revisado las conexiones punto a punto por medio de Sockets (Unicast). •  Sin embargo hay una gran colección de aplicaciones que requieren enviar tráfico a múl6ples des6nos como son: –  Difusión de vídeo –  Difusión de audio –  Difusión de no6cias –  e-­‐learning –  Entre otras Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Introducción •  Pero enviar la información a muchos des8nos replicando la misma información en la red es muy ineficiente y crea varios retrasos especialmente si el número de receptores es muy grande. D1
D2
S
D3
En Unicast los routers reenvían (encaminan) un paquete recibido solo a través de una de sus interfaces D4
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Broadcast (Difusión) •  Definición Servicio de envío a todos los miembros de una (sub) red. Todos los receptores de la red deben recibir una copia del mensaje. U6liza UDP D1
D2
S
D3
D4
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Broadcast –  Existen tecnologías que soportan la difusión de información de forma natural •  Topologías 6po bus: Ethernet •  Topologías en anillo •  Redes por satélite o cable –  Por otro lado hay tecnologías donde es costoso construir servicios de difusión •  Conmutadores, routers, bridges… Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Ventajas y Desventajas •  U6lidad: Cuando se desconoce la red –  Buscar algún servidor que a6ende terminales sin disco (BOOTP) –  Conocer los servidores ac6vos: day6me, echo… –  Búsqueda de usuarios en la red: finger •  Desventajas –  Mucha carga a ancho de banda •  Todos los host deben recibir el paquete –  Es necesario realizar múl6ples copias –  Pueden provocarse tormentas de mensajes –  Routers: deben tener una opción para inhibir la difusión de mensajes. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Direcciones IP •  Cuatro 6pos diferentes de direcciones broadcast: –  Broadcast limitado •  Dirección: 255.255.255.255 •  Nunca es redirigido por un router hacia la red exterior. •  Se u6liza en el proceso de configuración de host (p. e. DHCP). –  Broadcast dirigido a red •  Dirección : Iden6ficador de red + Iden6ficador de host a 1. –  <id de red>.255.255.255 •  Puede ser redirigido por los routers al exterior pero esta opción puede ser deshabilitada. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza –  Broadcast dirigido a subred •  Dirección: Iden6ficador de red + Iden6ficador de subred + Iden6ficador de host a 1 –  <id de red>. <id de red>.255.255 –  Broadcast dirigido a todas las subredes •  Dirección: Iden6ficador de red + Iden6ficador de subred y de host a 1. •  <id de red>. <id de red>.<id de red>.255 •  Para la red 210.25.23.0, con máscara de subred 255.255.255.192, las direcciones broadcast para todas las subredes sería 210.25.23.255 •  Si una red no 6ene subneeng es lo mismo que un broadcast dirigido a red Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Direcciones Broadcast •  Red Ethernet –  Subred de clase B •  Dirección de una red de clase B: 138.4.0.0 –  Dirección de subred: 0.0.23.0 –  Máscara de red 255.255.255.0 –  Dirección de difusión a subred: 138.4.23.255 •  Dirección de difusión a todas las subredes:138.4.255.255 Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Envío y Recepción de mensajes •  Envío de paquetes –  Envío a dirección de difusión y a un puerto •  Recepción de paquetes –  El paquete se recibe en la cola del puerto –  El paquete se dis6ngue por la dirección de envío Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Ejemplo •  Envío a: dir = 138.4.23.255, puerto = 13 –  Se envía el paquete UDP al servidor de echo de los ordenares de la subred •  Envío a: dir = 138.4.23.255, puerto = 79 Datos = “jigueroa” –  Se envía el paquete UDP de búsqueda del usuario jigueroa al servidor finger de todos los host de la subred Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Broadcast en Internet •  En Internet no es posible hacer un envío broadcast. Si u6lizamos la dirección 255.255.255.255 el envío se difunde en la red local únicamente, no pasa más allá. •  Dicho de otro modo, el paquete broadcast es tratado como si tuviera TTL=1, cualquiera que sea el valor de TTL que realmente tenga •  Esto se hace para preservar la ‘salud’ de la red. De lo contrario cualquier usuario desaprensivo o despistado podría saturar la red Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Broadcast ‘dirigido’ •  En Internet cuando se define una red automá6camente se define una dirección broadcast en dicha red. Dicha dirección es la más alta existente en esa red (parte host toda a unos). •  Por ejemplo si definimos la red 130.206.4.0/23 su dirección de broadcast es 130.206.5.255 •  En principio cualquier host puede hacer un envío broadcast a una red remota u6lizando dicha dirección esto se conoce como ‘broadcast dirigido’ Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Ataques con broadcast dirigido •  A finales de los 90 se produjeron diversos ataques u6lizando broadcast dirigido. La técnica consispa en enviar un paquete a la dirección broadcast de una red grande poniendo una dirección de origen falsa (la del host a atacar). Cuando ese host recibía las respuestas de los pings su consumo de CPU crecía enormemente. •  Por tanto no se permite el broadcast dirigido. Si se recibe un ping broadcast dirigido solo lo responde el router que da acceso a esa red. •  En los routers cisco el broadcast dirigido se controla con el comando ‘ip directed-broadcast’ a nivel de interfaz. Por defecto este comando está puesto a ‘no’ en todas las interface. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Mul6cast IGMP Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Mul6cast •  Se u6liza en las comunicaciones uno a varios •  Con Mul6cast los routers pueden reenviar (encaminar) un paquete recibido a través de más de una (varias) de sus interfaces Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Mul6cast •  Servicio eficaz de comunicación en grupo –  Comunicación de N a N •  Evita la mul6plicación de tráfico –  Normalmente basado en el envío de datagramas •  Se puede simular con unicast –  Creando una malla entre todos los miembros •  Muy ineficaz (n-­‐plica tráfico) •  Es un caso par6cular de difusión –  Grupo:Todos los host de una (sub) red •  El grupo es fijo Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Grupos mul6cast de Internet •  Grupo dinámico –  Operaciones de conexión y desconexión explícitas •  Miembro del grupo = conectado al grupo –  Acceso libre: cualquiera puede conectarse –  Tamaño ilimitado •  Un grupo puede abarcar toda la Internet •  Grupo de recepción –  Envío sin restricciones: para enviar a un grupo no es necesario ser miembro del grupo –  Mensajes enviados al grupo son recibidos por todos los miembros del grupo Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Direcciones clase D •  Un grupo de mul6cast se iden6fica con –  dirección IP de clase D •  Formato: 1110xxxxx....xxxx –  Una comunicación u6liza además una dirección de puerto •  Iden6fican grupos globales en Internet •  Grupos permanentes: –  direcciones asignadas administra6vamente por IANA •  Internet Assignment Number Authority •  tp://tp.isi.edu/in-­‐notes/iana/assignments/mul6cast-­‐addresses •  MBONE: –  red para distribución de audio y vídeo por internet •  Direcciones reservadas: 224.2.*.* Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Ejemplos de grupos asignados Reservados por IANA •  BASE-­‐Address.mcast.net: 224.0.0.0: reservada •  All-­‐Systems.mcast.net: 224.0.0.1 –  Todos los sistemas en la subred (local), IGMP •  All-­‐Routers.mcast.net: 224.0.0.2 –  Todos los routers en la subred (local) •  DVRMP.mcast.net: 224.0.0.4 –  Routers con “Distance Vector Mul6cast Rou6ng Prot.” •  PIM-­‐ROUTERS.mcast.net: 224.0.0.13 –  4Routers con “Protocol Indpendent Mul6cas6ng” Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Funcionamiento •  El Mul6cast trabaja bajo el protocolo UDP, debido a que no se envían confirmaciones (ACK) que podrían saturar la red. •  Un paquete mul6cast es entonces un datagrama convencional dirigido a una dirección mul6cast. •  El mecanismo de trabajo es básicamente el siguiente: se guardan los datos en un datagrama, se envía el datagrama, los ruteadores se encargan de todo el trabajo intermedio y se entrega una copia del datagrama a cada miembro del grupo correspondiente. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Funcionamiento •  Para recibir los datos, cada miembro del grupo debe estar escuchando en un puerto adecuado y debe estar listo para procesar el datagrama; el anfitrión reconoce el paquete porque pertenece al grupo. •  La única diferencia que se presenta en mul6cast respecto al manejo de datagramas en UDP se refiere a un campo de la trama IP, el byte llamado TTL (6me to live). Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Funcionamiento •  En mul6cast el programador debe asignar este byte (que puede tomar valores desde 0 hasta 255). •  El TTL fue diseñado para prevenir la ocurrencia de loops infinitos entre ruteadores mal configurados y da una es6mación del número de ruteadores que un datagrama puede atravesar antes de ser descartado. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza TTL •  Por lo tanto en mul6cast el TTL proporciona un método ad hoc para limitar qué tan lejos puede llegar un datagrama en un envío mul6cast. •  Cada vez que un datagrama pasa por un ruteador su TTL se decrementa en al menos uno y se descarta cuando su TTL es cero. •  La correspondencia entre el valor del TTL y la distancia geográfica que alcanzará un datagrama en mul6cast no es precisa, una TTL de 127 puede llegar a miembros de un grupo en todo el mundo, mientras que un TTL de 1 se entregará solo a anfitriones que pertenezcan al grupo y estén en la subred local. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Limitación de alcance: TTL •  El paquete IP 6ene un campo TTL (Time To Live) –  Limita la vida de los paquetes IP –  Limita el máximo número de routers a cruzar •  En mul6cast se u6liza para limitar la alcanzabilidad –  Típicamente: campus => 4-­‐16, pais => 32-­‐64, .... Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza TTL Máximo 64 saltos
Mundo
TTL-Threshold = 64
Máximo 32 saltos
TTL-Threshold = 48
Red de la
Universidad
Autónoma de
Aguascalientes
Máximo 15 saltos
Mexico
America
TTL-Threshold = 16
Red de la UNAM
TTL-Threshold = 0
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Ámbito
TTL
LAN
1
Organización
15
País
47
Continente
63
Global
127
Delimitación de Ámbito por dirección (RFC 2365) •  Se asigna un significado especial a determinados rangos de direcciones mul6cast. •  Similar a la delimitación por TTL, pero el filtro en el router se realiza por la dirección. Devuelve al TTL su autén6co significado y suprime la restricción de número de saltos máximo. Rango
Ámbito
224.0.0.0/24
(224.0.0.0-224.0.0.255)
Nivel de enlace (LAN)
224.0.1.0-238.255.255.255
Global.
239.0.0.0 – 239.191.255.255
Reservado para usos futuros
239.192.0.0/14
(239.192.0.0-239.195.255.255)
Organización
239.196.0.0 – 239.254.255.255
Reservado para usos futuros
239.255.0.0/16
(239.255.0.0-239.255.255.255)
Nivel de enlace (LAN)
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Limitación del ámbito por dirección
(RFC 2365, 7/1998)
Red de la UAM
224.0.1.0-238.255.255.255
Mexico
America
Filtra 239.192.0.0/14
Mundo
Red de la UNAM
Filtra 239.255.0.0/16
239.255.0.0/16
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza 239.192.0.0/14
Filtrado de paquetes mul6cast Cada nivel en la red filtra los paquetes que llegan de la red •  La interfaz de red acepta –  Su dirección, dirección de difusión, direcciones mul6cast •  Algunas tarjetas aceptan un número limitado de dir. Mul6cast •  Modo promiscuo: acepta cualquier dirección mul6cast, difusión •  El nivel ysico (el manejador de disposi6vo) filtra –  Paquetes de protocolo no soportados (IP, ARP, ...) –  Algunas direcciones mul6cast Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza •  El nivel de red IP filtra –  Direcciones IP no conectadas (unicast y mul6cast) •  El nivel de transporte (UDP) filtra –  Segmentos dirigidos a puertos no atendidos •  Envía mensaje ICMP Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Mul6difusión entre segmentos •  Será necesario contar con encaminadores mul6difusión (mrouters) que puedan procesar estos datagramas de modo que una copia de los mismos alcance cada uno de los equipos miembros del grupo mul6difusión. •  Esto se consigue mediante un árbol de entrada mul6cast (mul6cast delivery tree) que se construye a través de los encaminadores y que 6ene por ramas todos los equipos que forman parte del grupo mul6cast. •  Este árbol de entrega es dinámico, en función de la conexión/desconexión de los miembros del grupo. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Arbol mul6cast Conecta los miembros del grupo •  Ejemplo: –  Grupo = {P3, P4, P8,.., P12} –  P1, P2, P5, P6 y P7 no están en el grupo •  Routers: –  Realizan copias a los host conectados al grupo –  Se comunican con IGMP con los host Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Grupo = {P3, P4, P8,.., P12}
P1, P2, P5, P6 y P7 no están en el grupo
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP IGMP (Internet Group Management Protocol): Ejemplo: •  Protocolo de suscripción del host al grupo •  El router sondea periódicamente a los host de su red •  Los host responden con los grupos a los que se han suscrito los usuarios –  No respuesta implica desconexión Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Protocolo IGMP (Introducción) •  Protocolo que permite a los hosts comunicar su interés, o no, en pertenecer a grupos mul(cast, dinámicamente. •  Los mensajes IGMP van encapsulados dentro de datagramas IP, con número de protocolo IP = 2, TTL = 1 y con la opción IP Router Alert en la cabecera IP. •  Existen 3 versiones incrementales. La más usada es la versión 2. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Protocolo IGMP •  IGMP (Internet Group Management Protocol), está descrito en los RFC 1112, 2236 y 3376 de sus versiones 1, 2 y 3, respec6vamente. •  Ges6ona la membrecía de las terminales a los dis6ntos grupos mul6cast. •  Proporciona a los routers mul6cast información acerca del estado de membrecía del host de una red. •  Le permite a los mrouters saber en todo momento los grupos mul6cast que están ac6vos en cada una de las interfaces. •  IGMP NO es un protocolo de encaminamiento mul6cast Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Mensajes IGMP Tipo
Emitido
por
Función
Dirección
de destino
Consulta General
(General Query)
Routers
Preguntar a los hosts si están
interesados en algún grupo
multicast
224.0.0.1
Consulta específica de
grupo (Group-Specific
Query)
Routers
Preguntar a los hosts si están
interesados en un determinado
grupo multicast
La del
grupo en
cuestión
Consulta específica de
grupo y fuente (Groupand-Source-Specific
Query)
Routers
Preguntar a los hosts si están
interesados en un determinado
grupo multicast de una serie de
fuentes determinada
La del
grupo en
cuestión
Informe de Pertenencia
(Membership Report)
Hosts
Informar a los routers que el
host está interesado en un
determinado grupo multicast
(indicando una serie de fuentes
a incluir o a excluir)
224.0.0.22
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Versión Acciones Tipo Mensajes IGMP 1 • Unirse a un grupo • Pregunta-­‐Respuesta • Abandonar un grupo • Membership Query. • Membership Report. IGMP 2 • Unirse a un grupo • Pregunta-­‐Respuesta General • Pregunta-­‐Respuesta Específica • Abandonar un grupo • Elección del router mul6cast • Membership Query • General Query • Group-­‐Specific Query • Membership Report versión 1 • Membership Report versión 2 • Membership Leave Group IGMP 3 • Las propias de las versiones 1 y 2 • Unirse a un grupo. Igual que en versiones anteriores, pero el Report se manda a 224.0.0.22. • Membership Query • General Query • Group-­‐Specific Query • Group-­‐and-­‐Source-­‐Specific Query • Membership Report versión 3 • Membership Report versión 1 • Membership Report versión 2 • Membership Leave Group versión 2 Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP 1 -­‐ Unión a un grupo –  El host H que se quiera a un grupo G debe mandar un Membership Report a la dirección del grupo al que quiere unirse. Ej.: Host 2 quiere unirse al Grupo 1. Host A : Grupos 1 y 3
Host B
Host C: Grupo 2
MemberShip Report
Grupo 1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Router Multicasting
IGMP 1. Pregunta-­‐Respuesta –  Si el router no recibe ningún mensaje Report de algún grupo, entonces considera que ese grupo ya no existe. –  Sólo un host de cada grupo responde al router. Si un host en espera de contestar a una Query escucha un Report de otro host del mismo grupo, interrumpe su temporizador y cancela la respuesta. Host A: Grupos 1 y 3
Timer Grupo 1
Host B: Grupo 1
Host C: Grupo 2
Router Multicasting
MemberShip Query
Timer Grupo 1
Timer Grupo 2
Timer Grupo 3
MemberShip Report
Grupo 1
MemberShip Report
Grupo 2
MemberShip Report
Grupo 3
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP 1. Abandonar un grupo –  Cuando un host quiere abandonar un grupo simplemente deja de responder como miembro de ese grupo a los mensajes Membership Query del router. –  Ejemplo: Host C abandona el grupo 2. Host A: Grupos 1 y 3
Timer Grupo 1
Timer Grupo 3
Host B: Grupo 1
Timer Grupo 1
Host C: Grupo2
No responde
MemberShip Report
Grupo 1
MemberShip Report
Grupo 3
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Router Multicasting
MemberShip Query
IGMP 2. Pregunta-­‐Respuesta Específica –  El router pregunta por la existencia de miembros de un grupo concreto. Los host responden igual que a una Query general. Usando un 6empo de respuesta máximo menor(=1s) se reduce la latencia de abandono de grupo. Ej.: Host A : Grupos 1 y 3
Timer Grupo 1
Host B: Grupo 1
Host C: Grupo 2
Router Multicasting
MemberShip Group
Specific Query
Grupo 1
Timer Grupo 1
MemberShip Report
Grupo 1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP 2. Abandono de Grupo –  Ej.: Host A abandona el grupo 1. •  Si algún host contesta con un Report, entonces el router man8ene el grupo. Host A: Grupos 1 y 3
Host B: Grupo 1
Host C: Grupo 2
Router Multicasting
MemberShip Leave
Group - Grupo 1
Timer Eliminar Grupo 1
No responde
MemberShip GroupSpecific Query
Grupo
1
Timer Grupo 1
MemberShip Report
Grupo 1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP 2. Abandono de Grupo –  Ej.: Host C abandona el grupo 2. Host A: Grupos 1 y 3
Host B: Grupo 1
Host C: Grupo 2
Router Multicasting
MemberShip Leave
Group - Grupo 2
Timer Eliminar Grupo 2
No responde
MemberShip GroupSpecific Query
Grupo 2
Grupo 2 eliminado
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IGMP 3.
Acciones –  Las propias de las versiones 1 y 2 –  Unirse y dejar un grupo. Igual que en versiones anteriores, pero el mensaje de respuesta se manda a 224.0.0.22, y se pueden especificar fuentes dentro de los grupos a las que unirse. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Arbol de mul6cast entre routers –  Existen varios protocolos de interconexión de routers •  DVMRP (Distant Vector Mul8cast Rou8ng -­‐ Prot. RFC 1075, usado por MROUTED) •  PIM (Protocol Independent Mul8cast) •  MOSPF (Mul8cast Extension to Open Shortest Path First -­‐RFC 1584) Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Rou6ng Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP – Protocolo de mul6envío basado en el vector distancia •  La técnica de DVMRP es enviar tramas mul6cast como si fueran de broadcast (L3) usando técnicas intercambio de rutas ac6vas hasta llegar a los routers hojas (leaf routers). •  Las rutas ac6vas se calculan mediante el intercambio de tramas. Es un protocolo similar a RIP, con una limitación de hasta 32 saltos. •  Los Routers hoja (leaf router) si no 6enen ningún par6cipante del grupo de mul6cast, envía un mensaje de “poda” (prune) hacia arriba, para que no le envíen nuevos paquetes de ese grupo de mul6cast. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP
•  Forma un árbol de distribución intercambiando métricas entre los routers Ruta de distribución
S
R1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP •  La primera trama se trata como un broadcast Ruta de distribución
S
Distribución de Multicast
R1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP •  “podado del arbol” (prune) Ruta de distribución
Distribución de Multicast
S
DVMRP Prune (poda)
R1
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP •  Los Routers X e Y son quitados del árbol de distribución (pruned) Ruta de distribución
Distribución de Multicast
S
X
R1
Y
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP •  Se añade un nuevo miembro Ruta de distribución
S
Distribución de Multicast
DVMRP Graft (injerto)
R1
R2
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP •  Se genera un nuevo árbol de distribución. Ruta de distribución
Distribución de Multicast
S
X
R1
R2
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP Tuneles •  Las tablas de rou6ng de DVMRP son muy parecidas a las de RIP (usan el mismo formato para descubrir rutas – permite hasta 32 saltos). •  Por ello, DVMRP por si solo no sirve para conexión de dis6ntas redes a través de internet (número de saltos indefinido). •  Para conectar dos redes DVMRP a través de internet se u6lizan túneles de IP, de forma que la red sólo vea un salto entre un extremo y el otro. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza DVMRP Tuneles •  MBONE=Mul6cast Backbone MBONE
NO MBONE
(Internet)
–  Source Address la del router A –  Des(na(on address la del Router B. A
MBONE
•  Lo que se hace es encapsular en los routers de los extremos la trama mul6cast directamente sobre IP con S
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza B
R
Otros protocolos MOSPF (RFC 1584) •  Es una extensión del protocolo de rou6ng unicast OSPF. •  MOSPF incluye información de mul6cast en las tramas de aviso de estado de enlaces que ya usa OSPF para construir sus árboles de distribución. (solo funciona sobre redes OSPF) •  Todos los routers deben de conocer la topología completa de la red en cada momento a base de intercambiarse con6nuamente tramas de con los estados de los enlaces. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Otros Protocolos MOSPF -­‐ Consideraciones •  Problemas de escalabilidad –  Cambios frecuentes en los estados de los enlaces provoca bajadas de rendimiento importantes –  Hay que correr un algoritmo de Dijkstra (usado por OSPF para calcular la ruta óp6ma) para cada Fuente de mul6cast. •  No se debe de u6lizar en –  Redes con enlaces inestables –  Redes con muchos grupos simultáneos de mul6cast Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Aplicaciones Mul6cast •  Todas las aplicaciones mul6cast u6lizan UDP como protocolo de transporte –  No hay control de conges6ón –  No hay control de datagramas erróneos, duplicados, descartados, etc. •  Todas estas tareas quedan a cargo de la aplicación, que recibe información de la situación a través de los protocolos RTP (RealTime Transport Protocol)y RTCP. •  La inmensa mayoría de las aplicaciones disponibles para mul6cast son herramientas de comunicación mul6media (vídeoconferencia, distribución de vídeo, etc.). Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Aplicaciones •  Las aplicaciones del mul6cast son varias, desde las convencionales (audio y video) hasta las mas especializadas, como son: –  Juegos para varios jugadores (mul6player) –  Sistemas de Archivo Distribuidos –  Bases de Datos con Replicación –  Servicios de nombre y de directorio, en los que el cliente no necesita saber la dirección del servidor específico sino que hace una pe6ción mul6cast a un grupo genérico de servidores y recibe respuesta del mas cercano o del mas adecuado para sus propósitos. –  Servicios de Cache (caching). Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Aplicaciones Mul6cast •  Cuando apareció la red MBone (mul6cast backbone) en 1992 surgieron una serie de herramientas de videoconferencia de libre distribución que se u6lizaban para transmi6r reuniones del IETF. Esas herramientas están disponibles en: h€p://www-­‐mice.cs.ucl.ac.uk/mul6media/sotware/ aunque actualmente son poco u6lizadas. •  Uno de los programa más u6lizado en mul6cast actualmente sea el VideoLAN (www.videolan.org), que es un sotware para vídeo streaming y vídeo bajo demanda. Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza •  El catálogo de aplicaciones comerciales que soportan mul6cast va creciendo, por ejemplo: –  Windows Media (Microsot) –  Real Player (Real Video) –  Quick6me (Apple) –  IP/TV (Cisco) •  También se u6liza mul6cast en algunos programas de transferencia masiva de información, como el Norton Ghost, de Symantec Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Distribución de contenidos mul6media en una red unicast Red
unicast
Servidor de
vídeo
multicast
secundario
Servidor de
vídeo
multicast
principal
Tráfico multicast
Tráfico unicast
Servidor de
vídeo
multicast
secundario
Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Servidor de
vídeo
multicast
secundario
Clase Mul6castSocket public class Mul8castSocket extends DatagramSocket { public Mul8castSocket() throws IOExcep8on public Mul8castSocket(int port) throws IOExcep8on public void setTTL(byte al) throws IOExcep8on public byte getTTL() throws IOExcep8on public void joinGroup(InetAddress mcastaddr) throws public void leaveGroup(InetAddress mcastaddr) throws IOExcep8on public synchronized void send(DatagramPacket p, byte al) throws IOExcep8on } Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza IOExcep8on Ejemplo import java.net.*; public class mcast { public sta6c void main (String args[]) throws java.io.IOExcep6on { byte[] m = {'H','e','l','l','o'}; InetAddress group = InetAddress.getByName("228.5.6.7"); Mul8castSocket s = new Mul8castSocket(6789); s.joinGroup(group); DatagramPacket hi = new DatagramPacket(m, m.length, group, 6789); s.send(hi); byte[] buf = new byte[1000]; DatagramPacket recv = new DatagramPacket(buf, buf.length); s.receive(recv); s.leaveGroup(group); s.close(); } } Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza Protocolos para Streaming •  Existe 2 formas de realizar streaming: –  Directo (6empo real) •  Udp,rtsp Con esta alterna6va no se usa el máximo ancho de banda disponible por el cliente para descargar y visualizar el medio, sino que tan sólo se usa el ancho de banda necesario para ir reproduciendo el medio en 6empo real. Además no se produce una descarga completa del medio, sino que conforme se descarga se va descartando una vez ha sido u6lizado RTPS (Esta basado en HTTP) puede u6lizar udp y tcp –  Bajo demanda •  Tcp (h€p o tp) Arquitecturas Cliente/Servidor, Sem 2015-­‐1 M.I.Yasmine Macedo Reza