Fundamentos Esenciales de Redes de Datos: Streaming, Conmutación, DNS y Protocolo HTTP

Distribución y Flujo de Video en Redes

Características del Flujo de Video

El flujo de video consiste en secuencias de imágenes que se deben visualizar a velocidad constante. Las imágenes están codificadas digitalmente con elevada redundancia y se comprimen para reducir la tasa de bits. Esto puede degradar la calidad de las imágenes. Por lo tanto, a mayor tasa de compresión, menor tasa de transmisión y menor calidad de imagen, y viceversa.

El video comprimido para internet oscila entre 100 kbps (baja calidad) y más de 3 Mbps (alta resolución), lo que produce un elevado volumen de tráfico y de almacenamiento. El video puede verse en distintas calidades y el usuario puede elegir según su velocidad de conexión.

Arquitecturas de Servidores para Video

Video con Servidor Web Convencional

Se procede de manera similar a la descarga de un fichero de texto o imagen, y el video se reproduce en una aplicación de reproducción. Los inconvenientes son que hay un retardo elevado y no se permite streaming, es decir, no se procesa ni visualiza a la vez el contenido que se recibe.

Video con Servidor de Flujo Continuo (Streaming Server)

Requiere dos servidores que pueden o no compartir el mismo sistema físico: el servidor web se ocupa de las páginas web y los metaficheros (MF), y el servidor de video se ocupa de los archivos de video.

Utiliza UDP para evitar los retardos que introduce TCP, a veces en conjunto con RTP (utilizando RTP/UDP).
Se utiliza el protocolo de control RTSP para controlar el proceso de reproducción.

Video con Servidor Web Convencional y Metafichero (MF)

Se requiere un MF asociado a cada fichero de video en el servidor Web. El MF contiene la URL del fichero junto con el tipo de contenido. Hay un hiperenlace en la página web que contiene la URL del MF, no la URL del video. El video se descarga directamente en el reproductor y no interviene el navegador. Permite streaming (procesa el contenido mientras se recibe).

Procedimiento de Descarga con Metafichero

Al pinchar en el hiperenlace, se desarrolla una transacción HTTP/TCP y se descarga el MF al navegador.
El navegador utiliza el valor de la cabecera del mensaje HTTP de respuesta para llamar al reproductor y le pasa el MF.
El reproductor, con la URL del video en el MF, lo descarga mediante HTTP/TCP.

Una ventaja es que elimina el retardo del navegador cuando se accede directamente al fichero de video. El inconveniente es que hay mayor retardo, ya que se accede de igual forma que a un fichero de texto o imagen.

TCP transfiere en segmentos y desarrolla control de error, de congestión y de flujo. Se requiere un buffer grande para evitar la pérdida de algún segmento.

Opciones para el Envío de Video con Servidor de Flujo Continuo

En UDP (con jitter): El receptor retrasa la reproducción unos pocos segundos para absorber el jitter, por lo que requiere buffer en el reproductor del cliente. Aplica como solución en contextos controlados.
En UDP (a tasa constante): El receptor no retrasa la reproducción y no requiere buffer en el reproductor cliente. No aplica como solución en internet en contextos controlados.
En TCP: La calidad de reproducción es mejor. Retrasa la reproducción unos segundos para absorber el jitter y requiere buffer en el reproductor cliente, que se puede vaciar debido a los mecanismos de control TCP. No aplica como solución en internet en contextos controlados.

Tecnología DASH y Redes de Distribución de Contenidos (CDN)

Tecnología DASH (Dynamic Adaptive Streaming over HTTP)

Los flujos de video con HTTP presentan una carencia fundamental: todos los usuarios reciben la misma versión codificada del video, y no todos los usuarios disponen del mismo ancho de banda (AB).

Para adaptar el reproductor a las variaciones de AB, el usuario solicita de manera dinámica, con mensajes GET, segmentos de video de unos pocos segundos de duración, uno a uno, según el AB disponible para cada usuario. Cuando el AB es grande, solicita segmentos de video de tasa elevada (mayor calidad). Cuando el AB es pequeño, solicita segmentos de video de tasa baja (menor calidad). Esto permite adaptarse a las variaciones de AB durante una sesión de video.

Se requiere un archivo manifiesto en el servidor HTTP que contiene, para cada versión de video, su URL y la tasa de bits correspondiente.

Procedimiento Seguido por el Cliente con Tecnología DASH

Solicita el archivo de manifiesto.
Aprende las diferentes versiones disponibles para el video en cuestión.
Solicita segmentos de video (mensaje GET de HTTP para cada segmento, especificando la URL y los bytes de cada segmento).
Durante la descarga, el cliente mide el AB de recepción, determinando la tasa adecuada para descargar el siguiente segmento, lo que determinará la calidad de descarga.

Redes de Distribución de Contenidos (CDN)

Una CDN es una solución para la distribución eficiente de contenidos a través de internet, ya que supera los problemas de una solución centralizada con un único centro de datos.

Problemas de una Solución Centralizada

Punto Único de Fallo: Si el centro de datos y sus enlaces caen, es difícil distribuir contenidos.
Distancia al Cliente: La mayoría de los clientes están muy alejados del centro de datos, lo que implica que existen muchos ISP involucrados, mayor probabilidad de fallos en los enlaces y mayor probabilidad de congestión (TTMEE).
Uso Ineficiente: Es ineficiente el uso de recursos de transmisión.

Funciones de la CDN

Se distribuyen múltiples servidores geográficamente que almacenan copias de los contenidos (audio, video, imágenes, documentos). Para mejorar la experiencia del usuario, cada petición se redirecciona a un cluster de servidores.

Dependiendo del origen del contenido solicitado, una CDN no siempre almacena una copia del contenido en el cluster. El procedimiento a seguir para contenidos solicitados y no disponibles en el cluster es:

El cluster solicita dicho contenido a un cluster central.
El cluster almacena una copia local.
El cluster envía el contenido al usuario.

Tipos de Soluciones CDN

CDN Privadas: Propiedad de un proveedor de contenidos (como Google).
CDN Comerciales: Distribuyen contenidos de múltiples proveedores (como Akamai).

Conmutación de Redes: Paquetes vs. Circuitos

Conmutación de Paquetes

Utiliza un canal compartido en el que la información se trocea, similar a las redes de datos. Los recursos de la red se comparten de manera más eficiente y dinámica: cada comunicación los utiliza cuando los necesita para transmitir y luego los libera. Los recursos no se reservan ni se asignan, y hay competencia por ellos.

Al dividirse el flujo en paquetes, estos se envían de manera independiente unos de otros. Cada paquete se recibe, se procesa y se reenvía cuando es posible (Store & Forward). Los paquetes se intercalan o comparten el uso de los recursos en diferentes comunicaciones.

Una solución para organizar el envío o cómo proceder si los clientes quieren enviar paquetes de datos a la vez es utilizar una cola FIFO (Primero en Entrar, Primero en Salir). Esto puede producir retardo de espera, que puede crecer exponencialmente con la carga de tráfico y, por lo tanto, ocasionar congestión o un retardo no tolerable. El flujo de paquetes que se envían no es constante y, por lo tanto, utilizará el canal cuando esté disponible, por lo que se usa la multiplicación estadística de flujos.

Ventajas de la Conmutación de Paquetes

Asignación Dinámica: El canal solo se ocupa si se necesita.
No hay Bloqueo/Rechazo: Si el canal está ocupado, se espera.
Más Flexible: Posibles caminos alternativos que se eligen en cada salto por paquetes, y posible transmisión en paralelo (menor retardo).

Inconvenientes de la Conmutación de Paquetes

Congestión: Aumento del retardo.
Tasa por cada Paquete: Requiere dirección de destino + ID de paquete.
Retardo Variable: Dependiendo del tamaño del paquete y la posible carga en la red.
Posibles pérdidas parciales y posible reordenamiento de paquetes en el destino.

Conmutación de Circuitos

Utiliza un canal dedicado para cada comunicación, como las redes telefónicas. Cada comunicación dispone de recursos reservados de extremo a extremo. Existe capacidad de transmisión en los enlaces y capacidad de conmutación en cada nodo. La calidad es constante. La fase de establecimiento de la comunicación requiere una señalización previa y luego la transferencia de la comunicación.

Los recursos se dividen en circuitos en los que se comparten los recursos, y a cada comunicación se le asigna un circuito, reservando su recurso de manera dinámica o estática. Si los recursos no se asignan bien, estos quedan ociosos. Si se quieren muchas comunicaciones, los circuitos deben ser pequeños.

La capacidad de transmisión de cada enlace entre conmutadores se comparte mediante técnicas:

FDM (Multiplexación por División de Frecuencia): Se reparte la capacidad espectral.
TDM (Multiplexación por División de Tiempo): Se ranura el tiempo.

Ventajas de la Conmutación de Circuitos

Una vez que se establece el circuito y se reservan los recursos, el retardo de transmisión y propagación es constante, sin esperas en cola.
No se produce congestión y la calidad de servicio está garantizada.

Inconvenientes de la Conmutación de Circuitos

Hay un retardo de espera debido al tiempo de establecimiento del circuito antes de transmitir.
Un recurso puede estar ocioso, ya que hay periodos de inactividad.
Existe un posible bloqueo o rechazo de nuevas comunicaciones, ya que el número de recursos es finito.
No hay buffer de almacenamiento.
No es posible la transmisión en paralelo.

Jerarquía de Proveedores de Servicios de Internet (ISP) y Servicios de Capa

Jerarquía de ISP

ISP de Nivel 1: Es la infraestructura que provee a los ISP de Nivel 2. Disponen de redes y servidores propios para brindar servicio y contenidos. Proporcionan cobertura internacional. Son conocidos como redes troncales (ISPA, ISPB, ISPC).
ISP de Nivel 2: Proveen cobertura regional o nacional y están conectados a unos pocos ISP de Nivel 1. Si se quiere llegar a una parte de la red, un ISP2 tiene que enrutar tráfico a través de uno de los ISP de Nivel 1 (Red Regional).
ISP de Nivel 3: Se conectan a internet a través de uno o más ISP de Nivel 2 y se llaman ISP de acceso (Red de Acceso).

Puntos de Intercambio de Internet (IXP)

Un IXP es un punto físico con red propia, a través del cual múltiples ISP pueden establecer peering (conexión entre pares que reduce gastos e intercambia tráfico directamente en el mismo nivel).

Tipos de Servicios de Capas

Servicio Confirmado: El envío de una nueva PDU (Unidad de Datos de Protocolo) requiere confirmación de recepción de la PDU previa.
Servicio No Confirmado: El envío de una nueva PDU no requiere confirmación de recepción de la PDU previa.

Servicios Conectivos y No Conectivos

Se entiende como un acuerdo lógico previo a la transferencia de información entre entidades de sistemas diferentes. Pueden ser entre sistemas finales o entre todos los nodos que intervienen en las comunicaciones. Requiere tres fases: establecimiento, uso y liberación de la conexión.

Modelo OSI y Tipos de Servicio de Red

Modelo OSI y Conmutación de Paquetes

El Modelo OSI consta de las capas: Aplicación, Presentación, Sesión, Transporte, Red, Enlace y Física, con sus respectivas cabeceras.

La Capa 3 (Red) del modelo OSI especifica dos tipos de servicio de conmutación de paquetes:

Circuitos Virtuales (Servicio Conectivo): Conmuta y encamina paquetes en base a un Número de Circuito Virtual (CV).
Datagramas (Servicio No Conectivo): Conmuta y encamina paquetes en base a una dirección de destino.

La elección del tipo de red a utilizar se determina por las aplicaciones usuarias y el desarrollo tecnológico. La elección se debe al servicio que reciben los usuarios de la capa de red, la forma de establecer las rutas de origen y destino, la forma de administrar el encaminamiento, y la complejidad de la red y la lógica asociada.

Servicio Conectivo (Circuitos Virtuales)

Ventajas: Menos procesamiento por nodo (solo en base al número de CV), menor demora por nodo y garantiza la secuencia de las PDU.
Inconvenientes: Requiere establecimiento de la conexión, lo que conlleva cierta demora antes de transferir la información del usuario. Requiere información de estado por nodo y es menos seguro ante la caída de un nodo o enlace, por lo que hay que rehacer la lógica.

Servicio No Conectivo (Datagramas)

Ventajas: No requiere conexión lógica, por lo que la transferencia de la información al usuario es más rápida. No requiere información de estado por nodo y es más confiable ante una caída de un nodo o enlace, ya que cada PDU es independiente de las demás.
Inconvenientes: Hay más demora de procesamiento por nodo y no garantiza la secuencia de las PDU.

Protocolos Clave en la Arquitectura TCP/IP

Capa de Aplicación

Capa que soporta e interactúa con las aplicaciones usuarias (Telnet, FTP, SMTP, HTTP, DNS).

Capa de Transporte

Desarrolla la gestión de la comunicación entre entidades de transporte, en base a protocolos de extremo a extremo. Esta capa es transparente a los nodos de red. Los protocolos importantes son UDP y TCP.

Protocolo TCP (Transmission Control Protocol)

Protocolo orientado a la conexión en modo conectivo.
Proporciona transporte fiable de extremo a extremo.
Funciones: Fragmenta los paquetes si es necesario. Entrega la secuencia de datos de la capa de aplicación a la capa de red. En el destino, ensambla si es necesario y entrega a la capa de red de destino. Reordena y solicita retransmisiones si se requiere. Proporciona control de errores, de flujo y de congestión.

Protocolo UDP (User Datagram Protocol)

Protocolo no orientado a la conexión en modo no conectivo.
Proporciona transporte no fiable de extremo a extremo.
Es un protocolo muy sencillo, no provee control de flujo, errores ni congestión.
Se adecua para aplicaciones que no requieren control de secuencia ni de flujo, como las de tipo transaccional (consulta, petición-respuesta).

Capa de Red (IP)

Provee servicio no conectivo y no fiable. Desarrolla funciones relativas a la gestión de paquetes IP, direccionamiento y encaminamiento. No provee control de errores ni control de flujo.

Capa de Acceso a Red (Nodo a Red)

Denominada capa de acceso a red, no está especificada en la arquitectura TCP/IP y la lógica depende del tipo de enlace. Se especifica el protocolo ARP. Podemos determinar la MTU (Unidad Máxima de Transmisión) y llamamos trama a la PDU de esta capa que encapsula el datagrama IP.

Sistema de Nombres de Dominio (DNS)

Arquitectura y Funcionamiento del DNS

El sistema DNS se basa en un modelo Cliente-Servidor distribuido y no centralizado. Normalmente utiliza UDP como servicio de transporte (o a veces TCP) por el puerto 53. El cliente DNS, normalmente ubicado en los hosts, presta servicio a determinadas aplicaciones de red. Un servidor DNS puede actuar como servidor o cliente.

Inconvenientes de un DNS Centralizado

Si el DNS fuese centralizado, implicaría un diseño más simple, pero no es apropiado para internet, ya que:

Habría un único punto de fallo.
Tendría que manejar muchos datos, requiriendo muchas actualizaciones y una gestión difícil de mantener.
Habría un incremento de tráfico de consultas hacia un servidor central.
La mayoría de los clientes estarían muy alejados, lo que significaría retardos significativos.

Jerarquía de Servidores DNS

Servidor DNS Raíz

Disponen de todos los servidores DNS de nivel superior y conocen sus direcciones IP. Existen alrededor de 13, y cada uno es una agrupación (cluster) de servidores replicados, por seguridad y fiabilidad.

Servidores DNS de Nivel Superior (TLD)

Son los responsables de los dominios de nivel superior (dominios genéricos y geográficos). Disponen de un registro para cada dominio TLD, como registros tipo NS y tipo A para cada DNS autorizado en el dominio.

Servidores DNS Autorizados

Están en toda organización con hosts y son accesibles desde internet (servidores web, servidores de correo). Estos servidores están implementados, gestionados y mantenidos por la propia organización o por un ISP. Disponen de registros DNS que contienen los nombres de host y direcciones IP, y la dirección IP de los servidores Raíz.

Servidores DNS Locales

Estos no pertenecen a la jerarquía de servidores DNS. Cada ISP dispone de uno o varios. Pueden encontrarse cerca de los hosts de una organización en una misma LAN (ISP institucional) o separados por unos pocos routers (ISP residencial). Los hosts envían las consultas primero a este tipo de servidores, que pueden comportarse como simples servidores DNS resolviendo la consulta a partir de la caché o como DNS proxy.

Tipos de Consultas DNS

Recursiva: Cuando el servidor DNS consultado se involucra en la resolución por no disponer del recurso solicitado. Este actúa como proxy, reenviando la petición a otro servidor DNS. La respuesta recorre el mismo camino a la inversa. Los servidores DNS raíz no admiten consultas recursivas.
Iterativa: Cuando un servidor DNS consultado responde indicando redirigir la solicitud a otro servidor DNS por no disponer del recurso solicitado. Devuelve la dirección IP del servidor DNS más cercano al que redirigir la petición. Reducen la carga de trabajo de los servidores DNS en comparación con las consultas recursivas.
Inversa: Permite realizar una traducción inversa, es decir, traducir una dirección IP a un nombre de dominio. Son utilizadas por programas que efectúan diagnóstico o por servidores de correo y de ficheros para validar a los usuarios.

Caché DNS

La caché DNS es una funcionalidad importante del DNS que sirve para mejorar el rendimiento. Se hacen copias temporales en la memoria caché de resoluciones DNS. El resultado está involucrado en una consulta recursiva y también a nivel de cliente DNS en un host (en disco o en RAM).

La caché permite:

Reducir los retardos.
Reducir el número de mensajes, disminuyendo el tráfico DNS en la red.
Reducir la carga de tráfico para los servidores DNS.
Permitir que un servidor DNS, no autorizado para el recurso solicitado, resuelva una petición de inmediato.

Las copias en caché DNS deben tener un tiempo de vida limitado.

Arquitectura Web y Protocolo HTTP

Elementos de la Arquitectura Web

Páginas: Contienen objetos que, tras seguir las instrucciones del fichero HTML, se muestran en el navegador.
Objetos: Pueden ser HTML, imágenes, y cada uno es direccionable a través de una URL.
Direccionamiento URL: Identificación del protocolo : nombre del dominio : ruta de acceso al objeto : nombre del objeto.
Entidades Funcionales:
- Cliente Web: Comprende un agente usuario (software que actúa como interfaz entre usuario y aplicación web) y un Cliente HTTP (software de comunicación que implementa la parte cliente HTTP).
- Servidor Web: Es un software de acceso a ficheros y una base de datos que alberga objetos, cada uno direccionable con una dirección URL. Incluye el Servidor HTTP (software de comunicaciones que implementa la parte servidora HTTP).

Tipos de Conexiones TCP en HTTP

Conexión No Persistente

Se establece una conexión TCP propia para transferir cada objeto. Por cada objeto diferente habrá diferentes conexiones TCP y una única transacción HTTP. Es independiente de la ubicación física de los objetos.

Modo Serie: Solo una conexión TCP abierta en cada momento.
Modo Paralelo: Varias conexiones TCP abiertas a la vez.

Conexión Persistente

Por una única conexión TCP discurren todas las transacciones HTTP y se transfieren todos los objetos de una página si están todos en el mismo servidor. Si pasa un tiempo sin transacción, el servidor cierra la conexión TCP.

Sin Canalización: Solo una transacción HTTP a la vez.
Con Canalización: Admiten varias transacciones HTTP a la vez (procesamiento en cadena).

Protocolo HTTP

HTTP es el protocolo para la transferencia de recursos. Estos recursos pueden ser el resultado de una consulta a una base de datos, de la ejecución de un programa o de una traducción automática de un documento. Existen las versiones HTTP/1.0 y HTTP/1.1.

Este protocolo opera en base al modelo cliente-servidor. Se basa en transacciones de petición-respuesta: el cliente solicita objetos y genera peticiones; el servidor transfiere objetos y genera respuestas. Es un protocolo de demanda.

Protocolo Sin Estado y No Conectivo: El servidor no guarda información de clientes ni de transacciones, lo que simplifica el diseño de los servidores. Los servidores web pueden manejar muchas conexiones TCP y las correspondientes transacciones HTTP.
Es un protocolo no fiable y no seguro.
Utiliza TCP como servicio de transporte en la práctica.

Procedimiento de Conexión HTTP

El cliente solicita conexión TCP al puerto 80 del servidor.
El servidor acepta la conexión del cliente (se crea un socket de conexión en el servidor).
Navegador y servidor intercambian mensajes HTTP.
Se cierra la conexión TCP.

Mecanismos para Identificar Usuarios en HTTP

Autorización

Mecanismo para la identificación de usuarios previa a la solicitud al servidor. Tiene una cabecera de Authenticate. Los mensajes de solicitud deben contener credenciales (nombre de usuario y clave) que se teclean una vez, permaneciendo en la caché de la máquina.

Si es con estado, el servidor asocia una cookie de autorización.
Si es sin estado, contiene la credencial en cada solicitud.

Cookies HTTP

Mecanismo para identificar usuarios que permite identificar la combinación de ordenador-navegador. Es un procedimiento utilizado por muchos sitios web para hacer seguimiento de la actividad de sus usuarios y dar un mejor servicio, aunque de alguna manera viola la privacidad del usuario, ya que permite saber cosas sobre ellos.

Las cookies son soportadas por los ficheros del usuario y una base de datos en el servidor. El fichero del usuario es gestionado por el navegador, mientras que la base de datos está gestionada por el servidor. El usuario, cuando se conecta con una URL, envía la cabecera Cookie con el número de cookie asociado, que fue enviado por el servidor en la cabecera Set-cookie. La base de datos almacena el número de cookie asociado con un usuario.

Procedimiento de las Cookies

El usuario accede por primera vez a un sitio web que implementa Cookies: el servidor crea un número de identificación único para el usuario y también crea una entrada indexada con ese número de identificación en su base de datos. Responde con un mensaje que incluye la cabecera Set-cookie con el número de identificación.
El navegador, cuando recibe el mensaje de respuesta que contiene una cookie, añade una línea al archivo de cookies que gestiona, incluyendo el nombre del servidor y el número de identificador.
Si el usuario quiere navegar por la web, el navegador consulta el fichero de cookies y, si hay cookies para el sitio, extrae el número de identificación y lo incluye en la cabecera Cookie para cada solicitud.

Caché Web y Servidor Proxy

Caché Web

Es un procedimiento para la mejora de las prestaciones del servidor Web y permite reducir el tiempo de obtención de un objeto, sobre todo si el ancho de banda (AB) entre cliente-servidor es menor que el AB entre cliente y caché web. También permite reducir la carga de trabajo del servidor web. En la caché web se almacenan copias de objetos en una memoria temporal.

Surge un problema: si un objeto es actualizado o modificado en el servidor, la copia en caché ya no es válida. La solución práctica para esto es el uso del GET Condicional.

GET Condicional

Es un mecanismo HTTP para comprobar y garantizar la actualidad de los objetos en caché. Se implementa mediante mensajes GET que solicitan el objeto si ha sido modificado respecto a la copia que hay en caché. Utiliza la cabecera específica If-Modified-Since, que contiene la hora y la fecha de creación y actualización del objeto en caché.

Si el objeto no ha sido modificado, la respuesta al GET condicional que da el servidor es 304 Not Modified y el cuerpo del mensaje está vacío.
Si el objeto ha sido modificado, el servidor responde con 200 OK y el cuerpo del mensaje contiene el objeto. Su cabecera contiene Last-Modified con la fecha/hora de la última actualización.

Servidor Proxy

Satisface solicitudes HTTP en nombre de servidores web y tiene doble función:

De cara al cliente web, actúa como servidor HTTP.
De cara al servidor web, actúa como cliente web.

Este servidor almacena en disco copias de objetos solicitados por los clientes y también es utilizado para distribuir contenidos. Mejora el rendimiento de las comunicaciones a través del enlace de acceso y reduce la latencia del servicio.

Configuración de Navegadores

Los navegadores se configuran para dirigir solicitudes a uno o varios proxies. Esto requiere información por parte del ISP: nombre de las máquinas que actúan como proxy y el puerto por el que dan servicio.

Modelos de Arquitectura de Aplicaciones de Red

Modelo Cliente-Servidor

Está formado por dos entidades: un cliente, encargado de realizar las peticiones, y un servidor, encargado de atender dichas peticiones.

Cliente: Elemento de red con dirección IP que puede ser dinámica y que no posee comunicación con otros clientes.
Servidor: Se caracteriza por tener IP permanente, por estar activo en todo momento y por encontrarse en granjas de servidores.

Modelo Peer-to-Peer (P2P)

Se caracteriza porque está compuesto de equipos finales. A diferencia del anterior, en este no existe una entidad única para responder o emitir peticiones. Se trata de un modelo escalable.

No requiere de una infraestructura significativa, lo que reduce mucho los costes. Sin embargo, es un sistema difícil de gestionar y puede presentar problemas de seguridad, rendimiento y fiabilidad debido a su naturaleza descentralizada.

Modelo Híbrido

Está compuesto por elementos de las dos arquitecturas citadas anteriormente. Lo que se necesita en esta arquitectura es un servidor que detecte y ubique los peers.