• No se han encontrado resultados

Sistemas Distribuidos. Sistemas Distribuidos. Definiciones. Definición

N/A
N/A
Protected

Academic year: 2021

Share "Sistemas Distribuidos. Sistemas Distribuidos. Definiciones. Definición"

Copied!
21
0
0

Texto completo

(1)

Sistemas Distribuidos

Por: Mariela Curiel Basado en los textos : Sistemas Distribuidos Conceptos y Diseño

G. Coulouris, J. Dollimore, TimKinberg

Sistemas Distribuidos

Definiciones

Ejemplos

Desafíos en el diseño de sistemas

distribuidos

Modelos Arquitectónicos

Modelos fundamentales para describir

sistemas distribuidos

Definiciones

``Se define un sistema distribuido como

aquel en el que los componentes de

hardware y software, localizados en

computadores unidos mediante una

red, comunican y coordinan sus

acciones sólo mediante el paso de

mensajes´´, (c,d,k, 2001)

Definición

Esta definición tiene las siguientes

consecuencias:

?Concurrencia

?Inexistencia de un reloj global

(2)

Definiciones

``Un sistema distribuido se compone de

un grupo de computadores autónomos,

enlazados mediante una red y

equipados con un software de sistemas

distribuidos. Este software permite que

los computadores coordinen sus

actividades y compartan recursos.

Definiciones

Los usuarios de un sistema distribuido

bien diseñado deberían percibir un

sistema de computación único e

integrado, aun cuando las máquinas

estén dispersas geográficamente´´

(c,d,k, 1998)

Definiciones

``Un sistema distribuido es un grupo de

computadores independientes que son

percibidas por los usuarios como un

único computador´´, (tanenbaum, 1995)

Ejemplos

Internet

Intranets

(3)

Desafíos

Heterogeneidad Extensibilidad Seguridad Escalabilidad Tolerancia a Fallas Concurrencia Transparencia

Desafíos: Heterogeneidad

La heterogeneidad se aplica en los

siguientes elementos:

?Redes ?Hardware de computadores ?Sistemas operativos ?Lenguajes de programación ?Implementaciones de diferentes desarrolladores

Desafíos: Heterogeneidad

Middleware

: es el estrato de software

que provee una abstracción de

programación, así como un

enmascaramiento de la heterogeneidad

subyacente de las redes, hardware,

sistemas operativos y lenguajes de

programación. Ejem: Corba, Java RMI

Desafíos: Heterogeneidad

Heterogeneidad y código móvil

?Código Móvil: código que puede enviarse

desde un computador a otro y ejecutarse en este último.

?El concepto de máquina virtual ofrece un

modo de crear código ejecutable sobre cualquier hardware

(4)

Desafíos: Extensibilidad

Es la característica que determina si el

sistema puede extenderse de varias

maneras. Un sistema puede ser abierto

o cerrado con respecto a extensiones

de hardware o de software.

Para lograr la extensibilidad es

imprescindible que las interfaces clave

sean publicadas.

Desafíos: Extensibilidad

Los Sistemas Distribuidos Abiertos pueden extenderse a nivel de hardware mediante la inclusión de computadoras a la red y a nivel de software por la introducción de nuevos servicios y la reimplementación de los antiguos.

Otro beneficio de los sistemas abiertos es su independencia de proveedores concretos.

Desafíos: Seguridad

La seguridad tiene tres componentes:

Confidencialidad: protección contra individuos no autorizados

Integridad: protección contra la alteración o corrupción

Disponibilidad: protección contra la interferencia que impide el acceso a los recursos

Desafíos: Seguridad

Existen dos desafíos que no han sido

resueltos en su totalidad:

?Ataques de denegación de servicio

(5)

Desafíos: Escalabilidad

Se dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el número de recursos y en el número de usuarios. El diseño de SD escalables presenta los

siguientes retos:

Control de costo de los recursos físicos: para

que un sistema con nusuarios sea escalable,

la cantidad de recursos físicos necesarios para soportarlo debería ser O(n).

Desafíos: Escalabilidad

Controlar la degradación del

rendimiento:

Ejm: Los algoritmos que

emplean estructuras jerárquicas se

comportan mejor frente al crecimiento

de la escala, que los algoritmos que

emplean estructuras lineales.

Evitar cuellos de botella:

los algoritmos

deberían ser descentralizados

.

Desafíos: Escalabilidad

Prevenir el desbordamiento de los

recursos de software

Desafíos: Tratamiento de

Fallos

Detección de fallos

: Ejem. Se pueden

utilizar sumas de comprobación

(checksums) para detectar datos

corruptos en un mensaje.

Enmarascamiento de fallos

: Ejem.

?Los mensajes pueden retransmitirse

(6)

Desafíos: Tratamiento de

Fallos

Tolerancia de fallos: los programas clientes de los servicios pueden diseñarse para tolerar ciertos fallos. Esto implica que los usuarios tendrán también que tolerarlos.

Recuperación de fallos: implica el diseño de software en el que, tras una caída del servidor, el estado de los datos puede reponerse o retractarse (rollback) a una situación anterior.

Redundancia: emplear componentes redundantes.

Desafíos: Concurrencia

Existe la posibilidad de acceso concurrente a un mismo recurso.La concurrencia en los servidores se puede lograr a través de threads.

Cada objeto que represente un recurso compartido debe responzabilizarse de garantizar que opera correctamente en un entorno concurrente.

Para que un objeto sea seguro en un entorno concurrente, sus operaciones deben

sincronizarse de forma que sus datos permanezcan consistentes.

Desafíos:Transparencia

Transparencia de acceso: permite acceder a los recursos locales y remotos empleando operaciones idénticas.

Transparencia de ubicación: permite acceder a los recursos sin conocer su localización. Transparencia de concurrencia: permite que varios procesos operen concurrentemente sobre recursos compartidos sin interferencia mutua.

Desafíos:Transparencia

Transparencia de replicación: permite replicar los recursos sin que los usuarios y los programadores necesiten su conocimiento. Transparencia frente a fallos: permite ocultar fallos.

Transparencia de movilidad: permite la reubicación de recursos y clientes en un sistema sin afectar la operación de los usuarios y los programas.

(7)

Desafíos:Transparencia

Transparencia de rendimiento: permite

reconfigurar el sistema para mejorar el

desempeño según varíe su carga.

Transparencia al escalado: permite al

sistema y a las aplicaciones expandirse

en tamaño sin cambiar la estructura del

sistema o los algoritmos de aplicación.

Modelos arquitectónicos

Modelo Arquitectónico de un SD: trata sobre la colocación de sus partes y las relaciones entre ellas. Ejem: modelo cliente-servidor y el modelo de procesos de ¨igual a igual¨ (peer-to-peer)

Diferentes modelos arquitectónicos: ?Capas de Software

?Arquitecturas de Sistema

?Interfaces y Objetos

Capas de Software

El término arquitectura de software se

refería inicialmente a la estructuración

del software como capas en un único

computador. Más recientemente las

capas son uno o varios procesos,

localizados en el mismo o diferentes

computadores, que ofrecen y solicitan

servicios.

Capas de Software

Plataforma: estas capas más bajas proporcionan servicio a las superiores y su implementación es dependiente de cada computador. Plataforma Aplicación de servicios Middleware Sistema Operativo Computador y Hw. de red

(8)

Capas de Software

Middleware :es una capa de software cuyo propósito es

enmascarar la heterogeneidad y proporcionar un modelo de programación conveniente para los programadores de aplicaciones Aplicación de servicios Middleware Sistema Operativo Computador y Hw. de red

Capas de Software:

Middleware

El middleware se ocupa de proporcionar bloques útiles para la construcción de componentes de software que puedan trabajar con otros en un sistema distribuido. En particular mejora el nivel de las

actividades de comunicación de los P. de aplicación soportando abstracciones como: llamadas a procedimientos remotos, comunicación entre un grupo de procesos, etc.

Capas de Software:

Middleware

Ejem: Sun RPC (llamadas a

procedimientos remotos), CORBA

(middleware orientado a objeto), Java

RMI (invocación de objetos remotos en

Java), DCOM (Modelo común de

objetos distribuidos de Microsoft)

Capas de Software:

Middleware

El middleware también puede

proporcionar otros servicios, aparte de

la comunicación, para su uso en

programas de aplicación. Por ejemplo:

gestión de nombres, seguridad,

almacenamiento persistente, etc.

(9)

Arquitecturas de Sistema

Modelo Cliente-Servidor

Servicios proporcionados por múltiples

servidores

Servidores proxy y caches

Procesos peer-to-peer

Modelo Cliente-Servidor

Servidor Cliente Cliente Servidor Invocación Resultado Invocación Resultado Proceso Computador

- El servidor puede o no estar en la misma máquina del cliente - Tanto servidores como clientes pueden ser iterativos o concurrentes

Servicios proporcionados por

múltiples servidores

servicio Servidor Cliente Cliente Servidor Servidor

-Los servidores pueden dividir el conjunto de objetos en los que está basado el servicio y distribuírselos entre ellos mismos. - Pueden mantener réplicas de los objetos en cada máquina.

Servidores Proxy y Caches

Cliente Servidor Proxy Servidor Proxy Servidor Web Cliente

-Un cache es un almacén de objetos de datos utilizados recientemente.

-Los caches pueden estar ubicados en los clientes o en un servidor Proxy que se puede compartir desde varios clientes.

-El propósito de los servidores proxy es incrementar la disponibilidad y las prestacionesdel servicio, reduciendo la carga en las redes de área Amplia y en los servidores WEB.

Servidor Proxy Servidor Web

(10)

Procesos Peer-to-Peer

Todos los procesos desempeñan tareas semejantes, interactuando cooperativamente como iguales para realizar una actividad distribuida o cómputo sin distinción entre clientes y servidores

Los procesos pares mantienen la consistencia de los recursos y sincroniza las acciones a nivel de aplicación. Servidor Proxy Aplicación Código de Coord. Servidor Proxy Aplicación Código de Coord. Servidor Proxy Aplicación Código de Coord.

Interfaces y Objetos

Una interfaz de un proceso es la

especificación del conjunto de funciones que se pueden invocar sobre él.

En lenguajes orientados a objetos, los procesos distribuidos pueden ser construidos de una forma más orientada al objeto. Las referencias a estos objetos se pasan a otros procesos para que se pueda acceder a sus métodos de forma remota. Esta es la aproximación adoptada por CORBA y Java RMI.

Otros Modelos

Arquitectónicos

Código Móvil

Agente Móvil: es un programa que se traslada en la red, de un computador a otro, realizando una tarea para alguien. Ejem. Recolecta información.

Computadores en red: se descarga desde un servidor remoto el sop y cualquier software de aplicación necesario.

Otros Modelos

Arquitectónicos

Clientes Ligeros: en el cliente sólo se

ejecuta una interfaz basada en

ventanas, mientras que la aplicación si

se ejecuta en un servidor remoto,

usualmente muy potente

(11)

Requisitos para el diseño de

Arquitecturas Distribuidas

Rendimiento

?Capacidad de respuesta: para obtener buenos tiempos de respuesta los sistemas deben estar compuestos por pocas capas de software y la cantidad de datos transferida debe ser pequeña (ejem. Uso de proxys y caches)

?Productividad: trabajos/unidad de tiempo

?Balance de cargas: applets, varios servidores o computadores para alojar un único servicio.

Requisitos para el diseño de

Arquitecturas Distribuidas

Calidad de Servicio

Algunas aplicaciones mantienen datos

críticos en el tiempo, flujos de datos que

precisan ser procesados o transferidos

de un proceso a otro a una tasa

pre-fijada.

QoS es la capacidad de los sistemas

para satisfacer dichos límites.

Requisitos para el diseño de

Arquitecturas Distribuidas

Calidad de Servicio

El satisfacer tales exigencias depende de la disponibilidad de los recursos en los instantes adecuados.

Cada recurso crítico debe reservarse para las aplicaciones que requieren QoS. Los

administradores de los recursos deben proporcionar la garantía. Las solicitudes de reserva que no se puedan cumplir se rechazan.

Requisitos para el diseño de

Arquitecturas Distribuidas

Aspectos de Fiabilidad (

que el sistema

funcione correctamente

)

Correctitud

Tolerancia de fallos

Seguridad:

?Confidencialidad ?Integridad ?Disponibilidad

(12)

Requisitos para el diseño de

Arquitecturas Distribuidas

Tolerancia a Fallos: las aplicaciones

estables deben continuar funcionando

correctamente en presencia de fallos de

hw, sw y redes.

? Se logra con redundancia

? Para hacer fiable un protocolo de

comunicación se emplean otras técnicas. Ejem. Retransmitir el mensaje.

Requisitos para el diseño de

Arquitecturas Distribuidas

Seguridad: necesidad de ubicar datos y

otros recursos sensibles sólo en

aquellos computadores equipados de

un modo eficaz contra el ataque.

Modelos Fundamentales

Los modelos fundamentales están implicados en una descripción más formal de las propiedades que son comunes en los modelos arquitectónicos.

Ayudan a localizar los problemas clave para los diseñadores de SD. Su propósito es especificar los problemas, dificultades y amenazas que deben superarse para desarrollar sistemas distribuidos fiables.

Modelos Fundamentales

Modelo de Interacción: Trata sobre el rendimiento y sobre la dificultad de poner límites temporales en un sistema distribuido Modelo de Fallos : intenta dar una

especificación precisa de los fallos que se pueden producir en procesos y en canales de comunicación.

Modelo de seguridad : posibles amenazas para los procesos y canales de

(13)

comunicación-Modelo de Interacción

Trata sobre el rendimiento y sobre la dificultad de poner límites temporales en un sistema distribuido.

El cómputo ocurre en procesos. Los procesos interactúan a través del paso de mensajes.

En la comunicación hay retrasos. El modelo estudia como afectan estos retrasos la coordinación de los procesos.

Modelo de Interacción

Rendimiento de los canales de comunicaciones:

?Latencia:retardo entre el envío de un mensaje por un proceso y su recepción por otro.

?Ancho de banda: cantidad total de información que se puede transmitir en un momento dado.

?Jitter o fluctuación: variación en el tiempo invertido en completar el reparto de una serie de mensajes.

Dos variantes del Modelo de

Interacción

Sistemas distribuidos síncronos

?El tiempo de ejecución de cada etapa de

un proceso tiene límites superior e inferior conocidos.

?Cada mensaje se recibe en un tiempo

limitado conocido.

?Cada proceso tiene un reloj local cuya tasa

de deriva sobre el tiempo real tiene un límite conocido.

Dos variantes del Modelo de

Interacción

Sistemas distribuidos síncronos

?Es posible sugerir valores para esos límites pero es difícil obtener valores realistas y dar garantías sobre los valores elegidos.

?Se pueden tener timeouts. Cuando expiran significa que ha fallado el proceso.

?Hay que garantizar ciclos suficientes de procesador, capacidad de red y proveer relojes con tasa de deriva limitadas.

(14)

Dos variantes del Modelo de

Interacción

Sistemas distribuidos asíncronos. Son aquellos donde no existen limitaciones sobre:

?La velocidad de procesamiento

?Los retardos de transmisión de mensajes

?Las tasas de deriva del reloj.

Los sistemas reales son frecuentemente asíncronos. Pero existen problemas que no pueden resolverse con este modelo.

Ordenamiento de Eventos

Aún cuando no hay relojes precisos la ejecución de un sistema se puede describir en términos de los eventos y su ordenación. Ejemplo:

1. X envía un mensaje de reunión

2. Y y Z responden

x envía

y lee y responde

z lee x, y y envía otra respuesta.

Ordenamiento de Eventos

x y z A t1 t2 t3 m1 m1 m2 m2 m3 envía envía envía Tiempo Físico

- Si los relojes pudieran sincronizarse pudiera utilizarse el tiempo Asociado localmente a c/mensaje enviado. Los mensajes en A se Mostrarían según el ordenamiento temporal.

Ordenamiento de Eventos

Tiempo lógico de Lamport

?Los mensajes se reciben después de su

envío

x envía m1 antes que y reciba m1 Y envía m2 antes que x reciba m2

?Las respuestas se envían después que se

reciben los mensajes

(15)

Ordenamiento de Eventos

x y z A t1 t2 t3 m1 m1 m2 m2 m3 1 2 3 4 envía envía envía Tiempo Físico 1 3 4 5 2 1 m 1 m 2

Modelo de Fallos

Intenta dar una explicación precisa de los

fallos que se pueden producir en los

procesos y en los canales de

comunicación para darnos una

comprensión de sus efectos.

Fallos por omisión

?De procesos

?De comunicaciones

Modelo de Fallos

Fallos de procesos

Ruptura accidentada del procesamiento. Es deseable si el resto de los procesos que

interactúan con el proceso interrumpido, o bien funcionan correctamente o se detienen.

El método de detección de ruptura descansa en timeouts.

Modelo de Fallos

Fallos de procesos

Fail- Stop: es cuando el resto de los procesos puede detectar con certeza que cierto proceso interrumpio su ejecución. Se puede detectar en un sistema síncrono por los timeouts.

(16)

Modelo de Fallos

Fallos por omisión de comunicaciones.

?Fallos por omisión de envíos

?Pérdida de mensajes entre los buffers

?Fallos por omisión de recepción.

Envía m Recibe Proceso p Proceso q Canal de comunicación Buffer de Mensajes salientes Buffer de Mensajes entrantes Fallos por omisión de envío Fallos por omisión de recepción Fallos por

omisión del canal

Modelo de Fallos

Fallos arbitrarios: cualquier tipo de error.

?Procesos: se omiten pasos del procesamiento

o se realizan pasos adicionales, no intencionados.

?Canales: se corrompe el contenido de un

mensaje o se repiten mensajes. Estos fallos se pueden reconocer y ocultar o enmascarar.

Transmitir mensajes arbitrariamente, comenter omisiones, un proceso puede realizar un paso incorrecto o Proceso o Canal

Arbitrario (bizantino)

El mensaje llega a la cola de mensajes entrantes pero el proceso no lo recibe. Proceso

Omisión de recepción

El procesos envía pero el mensaje no se coloca en el buffer de mensajes salientes Proceso

Omisión de Envío

Un mensaje en el buffer saliente nunca llega al buffer de mensajes entrantes Canal

Omisión

El proceso para y deja de funcionar. Otros procesos pueden no ser capaces de detectar su estado. Proceso

Ruptura

El proceso para y deja de funcionar. Otros procesos pueden detectarlo. Proceso Fail-stop (fallo-parada) Descripción Afecta a Clase de Fallo

Modelo de Fallos

Fallos de temporización

?Existen en los SD síncronos donde se

establecen límites. Fallos de reloj y fallos de prestaciones.

?En un SDA un proceso pude terminar mas

tarde pero no hay un fallo porque no se ha dado ningún tipo de garantía.

?Los SOP a tiempo real se diseñan con vistas a

(17)

Modelo de Fallos

La transmisión del mensaje toma más tiempo del límite permitido. Canal Prestaciones El proceso excede el límite de ejecución Proceso Prestaciones

El reloj local del proceso excede el límite de su tasa de deriva sobre el tiempo real. Proceso Reloj Descripción Afecta a Clase de Fallo

Modelo de Fallos

Enmascaramiento de fallos ?Ocultar el fallo

?Convertirlo en un tipo razonable

Fiabilidad y comunicación uno a uno. El término comunicación fiable se define en términos de validez e integridad.

?Validez: cualquier mensaje en el buffer de salida llega eventualmente al buffer de mensajes entrantes.

?Integridad: el mensaje recibido es idéndico al enviado y no se reparten mensajes por duplicado

Modelo de Fallos

Amenazas de Integridad

? Protocolos que retransmiten pero no usan

números de secuencia para evitar que el mismo mensaje llegue duplicado.

?Usuarios mal intencionados que insertan

mensajes inválidos, repiten mensajes antiguos o modifican mensajes autenticos.

Modelo de Seguridad

La seguridad de un SD puede lograrse

asegurando los procesos y los canales

empleados para sus interacciones y

protegiendo los objetos que se

encapsulan contra el acceso no

autorizado.

(18)

Modelo de Seguridad

Protección de Objetos

?Los objetos pueden contener datos

privados y públicos o compartidos.

?Se otorgan derechos de acceso que

especifican a quien se permite realizar ciertas operaciones sobre un objeto. Los usuarios son los principales beneficiarios de estos derechos de acceso.

Modelo de Seguridad

Protección de Objetos

? A cada invocación y a cada resultado se le asocia la autoridad con que se ordena. Tal autoridad se denomina principal .

?El servidor es responsable de verificar la identidad del principal tras la invocación y comprobar que dispone de los diferentes derechos para realizar operaciones sobre el objeto.

?El cliente puede comprobar la identidad del principal tras el servidor para asegurar que el resultado proviene del servidor requerido.

Modelo de Seguridad

Cliente Servidor Invocación Resultado red Derechos de acceso Objeto

Principal (usuario) Principal (servidor)

Modelo de Seguridad

Asegurar procesos y sus interacciones ?Cierto tipo de aplicaciones son más propensas a

los ataques.

?Para este tipo de aplicaciones probablemente habrá ataques a los procesos de los que se componen tales aplicaciones y a los mensajes que viajan entre los procesos.

?Cómo podemos analizar estas amenazas para

(19)

Modelo de Seguridad

Modelo de amenazas de seguridad El enemigo: es capaz de enviar cualquier

mensaje a cualquier proceso y también de leer o copiar cualquier mensaje entre un par de procesos. El ataque puede venir de un computador legitimamente conectado o de una máquina no autorizada.

Proceso P m m´Proceso Q

Copia dem El enemigo

Modelo de Seguridad

Amenazas a procesos : cualquier proceso puede recibir mensajes de otro proceso y bien pudiera no ser capaz de identificar la identidad del emisor. Los protocolos incluyen la dirección IP del emisor, pero no es un problema generar un mensaje con una dirección falsa. No conocer cuál es el origen del mensaje es una amenaza al correcto funcionamiento de clientes y servidores.

Modelo de Seguridad

Amenazas a canales: un enemigo

puede copiar, alterar o insertar

mensajes según viajen a través de la

red. Otra forma es recopilar mensajes

para volver a enviarlo más tarde,

haciendo posible volver a enviar el

mensaje más de una vez.

Modelo de Seguridad

Cómo se pueden vencer las amenazas

de seguridad?

Criptografía y secretos compartidos

Autenticación

(20)

Modelo de Seguridad

Criptografía es la ciencia de mantener

los mensajes seguros y la encriptación

es el proceso de transformar el mensaje

de forma que quede oculto el contenido.

Se emplean claves secretas que

conoce el emisor y receptor.

Modelo de Seguridad

Autenticación: probar la identidad

probada por los emisores. La técnica

básica consiste en incluir dentro del

mensaje un fragmento encriptado que

contenga suficiente información para

garantizar la autenticidad del mensaje.

Modelo de Seguridad

Canales Seguros: para construirlos se

emplean técnicas de encriptamiento y

autenticación.

Un canal seguro es un canal de

comunicación que conecta un par de

procesos, cada uno de los cuales actúa

en representación de un principal.

Modelo de Seguridad

Un canal seguro presenta las siguiente propiedades:

Cada proceso conoce bien la identidad del principal en cuya representación se ejecuta el otro proceso.

Asegura privacidad e integridad (protección contra la manipulación)

Cada mensaje incluye un sello de carácter temporal, de tipo fisico o lógico, para prevenir el re-envío o la reordenación de los

mensajes.

(21)

Modelo de Seguridad

Otras posibilidades de amenaza del

enemigo son:

Denegación de servicio

Código móvil: puede incluir código que

accede o modifica los recursos que

están legitimamente disponibles para

los procesos del host pero no para el

creador del código.

Referencias

Documento similar

REQ: 1.001 Crear especialista. Son capturados todos los datos del especialista, salvados y cargados por el sistema. REQ: 1.002 Crear estudio neuropsicológico. Se capturan

El diagrama de despliegue para este sistema incluye la representación de una PC que realiza la función de servidor y una o más PCs Cliente conectadas al Servidor por medio

El servidor de peticiones retorna la unidad de tra- bajo creada para el cliente (ver caso de uso Atender Tarea Asignada por el Servidor Central. Sección Crear una Unidad de

La tecnología de búsqueda, líder de la industria de SharePoint Portal Server 2003 permite localizar documentos, planes de proyecto y mejores prácticas en recursos compartidos,

Otro ejemplo son las “Librerías de cliente/servidor” que son las que permiten hacer llamadas a funciones del servidor desde el cliente usando las funciones JavaScript

La implementación del sistema se basa en un esquema cliente-servidor mediante un flujo de operaciones que completan el siguiente proceso: en el cliente se recopilan todos los datos

El desarrollo de la presente Tesis, se ha basado en el diseño e implementación de una aplicación cliente-servidor que permitiera al cliente gestionar de forma dinámica la reserva

Se indica, para cada flujo y sentido (cliente-servidor y servidor-cliente para los juegos, sólo este último para el streaming, punto a punto para VoIP), tanto el tamaño medio de