Comunicación en los Sistemas Distribuidos

  1. Introducción a la Comunicación en los Sistemas Distribuidos
  2. Protocolos con Capas
  3. Introducción al Modelo Cliente - Servidor (C - S)
  4. Direccionamiento en C - S
  5. Primitivas de Bloqueo Vs. No Bloqueo en C - S
  6. Primitivas Almacenadas en Bu¤er Vs. No Almacenadas en C - S
  7. Primitivas Confiables Vs. No Confiables en C - S
  8. Implantación del Modelo C - S
  9. Llamada a un Procedimiento Remoto (RPC)
  10. Operación Básica de RPC
  11. Transferencia de Parámetros en RPC
  12. Conexión Dinámica (Dynamic Binding) en RPC
  13. Semántica de RPC en Presencia de Fallos
    1. El Cliente No Puede Localizar al Servidor
    2. Pérdida de Mensajes de Solicitud
    3. Pérdida de Mensajes de Respuesta
    4. Fallos del Servidor
    5. Fallos del Cliente
  14. Aspectos de la Implantación en RPC
    1. Protocolos RPC
    2. Reconocimientos
    3. Ruta Crítica
    4. Copiado
    5. Manejo del Cronómetro
  15. Areas de Problemas en RPC
  16. Comunicación en Grupo
  17. Aspectos del Diseño de la Comunicación en Grupo
    1. Grupos Cerrados Vs. Grupos Abiertos
    2. Grupos de Compañeros Vs. Grupos Jerárquicos
    3. Membresía del Grupo
    4. Direccionamiento al Grupo
    5. Primitivas Send y Receive
    6. Atomicidad
    7. Ordenamiento de Mensajes
    8. Grupos Traslapados
    9. Escalabilidad
  18. Fin


Introducción a la Comunicación en los Sistemas Distribuidos

La diferencia más importante entre un sistema distribuido y un sistema de un único procesador es la comunicación entre procesos [25, Tanenbaum].

En un sistema de un solo procesador la comunicación supone implícitamente la existencia de la memoria compartida:

En un sistema distribuido no existe la memoria compartida y por ello toda la naturaleza de la comunicación entre procesos debe replantearse.

Los procesos, para comunicarse, deben apegarse a reglas conocidas como protocolos.

Para los sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la forma de varias capas y cada capa tiene sus propias metas y reglas.

Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseño al respecto; una importante opción es la “llamada a un procedimiento remoto”.

También es importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre dos procesos.

Inicio:   Fin:

Protocolos con Capas

Debido a la ausencia de memoria compartida, toda la comunicación en los sistemas distribuidos se basa en la transferencia de mensajes[25, Tanenbaum].

Cuando el proceso “A” quiere comunicarse con el proceso “B”:

Los puntos de acuerdo necesarios incluyen lo siguiente: La ISO (Organización Internacional de Estándares) desarrolló un modelo de referencia que (ver Figura 8.1 [25, Tanenbaum]):


Capas, interfaces y protocolos en el modelo OSI.

Este modelo se denomina “modelo de referencia para interconexión de sistemas abiertos” (ISO OSI o modelo OSI) [26, Tanenbaum].

El “modelo OSI” está diseñado para permitir la comunicación de los sistemas abiertos:


Un mensaje típico tal como aparece en la red.

El “modelo OSI” distingue entre dos tipos generales de protocolos:

Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste de un conjunto de operaciones para definir el servicio que la capa está preparada para ofrecer a sus usuarios.

El protocolo de la capa “n” utiliza la información de la capa “n”.

Cada protocolo de capa se puede cambiar independientemente de los demás:

La colección de protocolos utilizados en un sistema particular se llama una “suite de protocolo” o “pila de protocolo”.

Inicio:   Fin:

Introducción al Modelo Cliente - Servidor (C - S)

El “modelo de la OSI” es una solución elegante y realmente aplicable en muchos casos, pero tiene un problema [25, Tanenbaum]:

Con enlaces del orden de decenas (o centenas) de miles de bits / segundo y cpu poderosas: Con enlaces del orden de millones de bits / segundo y computadoras personales: La mayoría de los sistemas distribuidos basados en LAN no utilizan los protocolos de capas completos, sí utilizan un subconjunto de toda una pila de protocolos.

El “modelo OSI” no dice nada acerca de la forma de estructurar al sistema distribuido.

El “modelo cliente - servidor” tiene como idea fundamental la estructuración del S. O. como:

El “modelo cliente - servidor” se basa en un “protocolo solicitud / respuesta”:


Modelo cliente - servidor.

Inicio:   Fin:

Direccionamiento en C - S

Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de éste [25, Tanenbaum].

Un esquema de direccionamiento se basa en la dirección de la máquina destinataria del mensaje:

Otro esquema de direccionamiento se basa en identificar los procesos destinatarios en vez de a las máquinas: Una variante utiliza machine.local-id en vez de machine.process: El direccionamiento machine.process presenta el serio inconveniente de que no es transparente: Otro método de direccionamiento consiste en asignarle a cada proceso una única dirección que no contenga un número de máquina: También existe el método de dejar que cada proceso elija su propio identificador: Al utilizar este sistema: Otro método utiliza hardware especial:


Inicio:   Fin:

Primitivas de Bloqueo Vs. No Bloqueo en C - S

Las primitivas de transferencia de mensajes consideradas anteriormente se denominan primitivas de bloqueo o primitivas síncronas[25, Tanenbaum]:

Una alternativa son las primitivas sin bloqueo o primitivas asíncronas: Una solución es: La desventaja de la solución es que cada mensaje de salida debe ser copiado desde el espacio del usuario al espacio del núcleo.

Otra solución es:

La desventaja radica en la dificultad de la programación basada en interrupciones a nivel usuario.

Generalmente se considera que las desventajas de las primitivas asíncronas no compensan las ventajas del máximo paralelismo que permiten lograr.

El criterio utilizado ha sido el siguiente:

Otro criterio establece lo siguiente: Desde el punto de vista del S. O. generalmente se considera el primer criterio; el interés está centrado en el manejo de los buffers y en la transmisión de los mensajes.

Desde el punto de vista de los lenguajes de programación se tiende a considerar el segundo criterio; el interés está centrado en el lenguaje de programación y sus facilidades de uso.

Generalmente a las primitivas de envío se las conoce como send y a las de recepción como receive y ambas pueden ser con bloqueo o sin bloqueo.

Una recepción sin bloqueo le indica al núcleo la localización del buffer y regresa el control:


Inicio:   Fin:

Primitivas Almacenadas en Buffer Vs. No Almacenadas en C - S

Las primitivas consideradas hasta ahora son esencialmente primitivas no almacenadas [25, Tanenbaum]:

Este esquema funciona bien cuando el servidor llama a receive antes de que el cliente llame a send.

El problema se presenta cuando el send se lleva a cabo antes que el receive:

Una solución consiste en: Si dos o más clientes utilizan un servidor con transferencia de mensajes sin almacenamiento en buffers: Otra solución consiste en hacer que el núcleo receptor mantenga pendientes los mensajes por un instante: La llamada a receive elimina un mensaje del buzón o se bloquea (si se utilizan primitivas con bloqueo) si no hay un mensaje presente.

Esta técnica se denomina primitiva con almacenamiento en buffers.

Los buzones tienen el problema de que son finitos y pueden ocuparse en su totalidad:

Otra solución utilizada es no dejar que un proceso envíe un mensaje si no existe espacio para su almacenamiento en el destino:


Inicio:   Fin:

Primitivas Confiables Vs. No Confiables en C - S

Hasta acá se ha supuesto que los mensajes enviados siempre serán recibidos [25, Tanenbaum], pero en la realidad, los mensajes se pueden perder por diversas causas.

Cuando un cliente envía un mensaje se le puede suspender hasta que el mensaje ha sido enviado:

Un enfoque de este problema consiste en volver a definir la semántica de send para hacerlo no confiable [23, Tanenbaum]: Otro método exige que el núcleo de la máquina receptora envíe un reconocimiento al núcleo de la máquina emisora: Otra solución aprovecha el hecho de que la comunicación cliente - servidor se estructura: En el esquema anterior la respuesta funciona como un reconocimiento a la solicitud (ver Figura 8.4 [25, Tanenbaum]):


Esquema de mensajes reconocidos en forma individual y esquema donde la respuesta se utiliza como reconocimiento de la solicitud.

Otra posibilidad es la siguiente:


Inicio:   Fin:

Implantación del Modelo C - S

Las principales opciones de diseño analizadas se resumen en [25, Tanenbaum]:

Existen 3 4 = 81 combinaciones, pero no todas son igual de buenas.

En el caso de mensajes compuestos por varios paquetes, el reconocimiento puede ser:

Otro aspecto interesante de la implementación es el protocolo subyacente utilizado en la comunicación c - s.

Los principales tipos de paquetes son los siguientes:

Algunos ejemplos de intercambio de paquetes para la comunicación cliente - servidor pueden verse en la Figura 8.5 [25, Tanenbaum].

Intercambio de paquetes en la comunicación cliente - servidor.

Inicio:   Fin:

Llamada a un Procedimiento Remoto (RPC)

El modelo cliente - servidor es una forma conveniente de estructurar un S. O. distribuido, pero posee una falencia [25, Tanenbaum]:

Una opción distinta fue planteada por Birrel y Nelson:


Inicio:   Fin:

Operación Básica de RPC

Una llamada convencional a un procedimiento, es decir en una sola máquina, funciona de la siguiente manera [25, Tanenbaum] (ver Figura 8.6 [25, Tanenbaum]):


Llamada a un procedimiento local.

Los parámetros pueden llamarse por valor o por referencia.

Un parámetro por valor:

Un parámetro por referencia: Otro mecanismo para el paso de parámetros es la llamada por copiar / restaurar: La decisión de cuál mecanismo utilizar para el paso de parámetros la toman los diseñadores del sistema y es una propiedad fija del lenguaje.

La ida es que una llamada a un procedimiento remoto (RPC) se parezca lo más posible a una llamada local:

Cuando el mensaje llega al servidor: Para el servidor es como si tuviera una llamada directa del cliente; lleva a cabo el trabajo y regresa el resultado a quien hizo la llamada, de la forma usual.

El stub del servidor recupera el control luego de la llamada y:

Cuando el mensaje regresa a la máquina cliente: Cuando el proceso que hizo la llamada obtiene el control luego de la llamada a read: Resumiendo, se pueden indicar los siguientes pasos como una llamada a un procedimiento remoto (ver Figura 8.7 [25, Tanenbaum]):


Llamadas y mensajes en una RPC, donde cada elipse representa un solo proceso que incluye el resguardo.

Se ha convertido la llamada local del procedimiento cliente al stub del cliente, en una llamada local al procedimiento servidor.

Inicio:   Fin:

Transferencia de Parámetros en RPC

El empacamiento de parámetros en un mensaje se llama ordenamiento de parámetros [25, Tanenbaum].

El mensaje también contiene el nombre o número del procedimiento por llamar; el servidor podría soportar varias llamadas y se el tiene que indicar cuál de ellas se necesita.

Cuando el mensaje llega al servidor:

La llamada real del resguardo al servidor es similar a la llamada original del cliente, excepto en que los parámetros son variables inicializadas a partir del mensaje recibido, en vez de ser constantes (ver Figura 8.8 [25, Tanenbaum]).

Ejemplo de cálculo remoto.

Los elementos del mensaje corresponden a:

Un mensaje que corresponda a un procedimiento remoto con “n” parámetros tendrá “n + 1” campos: Un aspecto importante es determinar cómo se debe representar la información en los mensajes: Es importante saber la organización del mensaje y la identidad del cliente.

También es importante determinar de dónde provienen los procedimientos resguardo:

Es posible tener un compilador que: Un aspecto también muy importante es cómo se transfieren los apuntadores, pues un apuntador solo tiene sentido dentro del espacio de direcciones del proceso en el que se utiliza.

Una solución es copiar en el mensaje la estructura para la cual se utiliza el apuntador y enviarlo al servidor, en tal caso los cambios que realice el servidor mediante el apuntador afectarán directamente al buffer de mensajes en el resguardo del servidor.

Inicio:   Fin:

Conexión Dinámica (Dynamic Binding) en RPC

Un tema fundamental es la forma en que el cliente localiza al servidor [25, Tanenbaum].

Un método consiste en integrar dentro del código del cliente la dirección (en la red) del servidor:

Una solución es la conexión dinámica para que concuerden los clientes y los servidores.

El punto de inicio de la conexión dinámica es la especificación formal del servidor, que indica el nombre del servidor, el número de versión y una lista de los procedimientos que proporciona.

Se tienen los tipos de parámetros para cada procedimiento y cada parámetro queda determinado como parámetro in, out o in-out.

La dirección es relativa al servidor.

El principal uso de la especificación formal es como entrada del generador de resguardos:

Cuando un programa (cliente) llama a cualquiera de los procedimientos definidos mediante esa especificación, el correspondiente procedimiento resguardo del cliente se liga con su binario.

Si se compila un programa servidor, los resguardos del servidor se le ligan también.

Cuando el servidor inicia su ejecución:

Un servidor puede cancelar su registro con el conector si ya no está preparado para prestar algún servicio.

El cliente localiza al servidor de la siguiente manera:

Es un esquema muy flexible pero el conector puede ser un cuello de botella con altas cargas de trabajo.

Inicio:   Fin:

Semántica de RPC en Presencia de Fallos

El objetivo de RPC es ocultar la comunicación al hacer que las llamadas a procedimientos remotos se parezcan a las llamadas locales [25, Tanenbaum].

El problema se presenta cuando aparecen los errores, ya que las diferencias entre las llamadas locales y remotas no son tan fáciles de encubrir.

Se consideraran las siguientes situaciones:


Inicio:   Fin:

El Cliente No Puede Localizar al Servidor

El servidor podría estar inactivo.

El servidor podría estar utilizando una nueva versión de la interfaz y nuevos resguardos, que no serían compatibles con la interfaz y los resguardos del cliente.

En el servidor, cada uno de los procedimientos regresa un valor:

Otra posibilidad para el tratamiento de los errores es mediante una excepción provocada por el error:


Inicio:   Fin:

Pérdida de Mensajes de Solicitud

El núcleo (kernel) debe inicializar un cronómetro al enviar la solicitud; si el tiempo se termina antes de que regrese una respuesta o reconocimiento, el núcleo vuelve a enviar el mensaje.

Si el mensaje realmente se perdió, el servidor no podrá indicar la diferencia entre la retransmisión y el original y todo funcionará bien.

Si el número de mensajes perdidos supera cierto límite, el núcleo puede asumir que el servidor está inactivo y se regresa a la situación “no se pudo localizar al servidor”.

Inicio:   Fin:

Pérdida de Mensajes de Respuesta

La pérdida de respuestas genera mayores problemas que la pérdida de solicitudes.

Se utiliza un cronómetro:

Ciertas operaciones se pueden repetir con seguridad tantas veces como sea necesario sin que ocurran daños; una solicitud con esta propiedad es idempotente.

Otras operaciones no son idempotentes, por ej. la transferencia de dinero:

Una forma de resolver el problema consiste en lo siguiente: Una protección adicional es tener un bit en el encabezado del mensaje para distinguir las solicitudes de las retransmisiones.

Inicio:   Fin:

Fallos del Servidor

Un fallo del servidor también se relaciona con la idempotencia pero no se puede resolver con números secuenciales (ver Figura 8.9 [25, Tanenbaum]).

Situaciones posibles de fallos en el servidor.

El problema es que el núcleo del cliente no puede decidir si se ha presentado la segunda o la tercera situación.

Las posibles soluciones son las siguientes:

La posibilidad de fallos del servidor distingue de manera clara los sistemas con un único procesador de los sistemas distribuidos:


Inicio:   Fin:

Fallos del Cliente

La cuestión es qué ocurre si un cliente envía una solicitud a un servidor y falla antes de que el servidor responda.

Se genera una solicitud de trabajo o cómputo que al fallar el cliente ya nadie espera; se dice que se tiene un cómputo huérfano.

Los principales problemas generados por cómputos huérfanos son los siguientes:

Las soluciones a los cómputos huerfanos son las siguientes [25, Tanenbaum]:


Inicio:   Fin:

Aspectos de la Implantación en RPC

El desempeño o performance es fundamental en los sistemas distribuidos [25, Tanenbaum].

El desempeño depende de manera crítica de la velocidad de la comunicación.

La velocidad depende en gran medida de la implantación.

Inicio:   Fin:

Protocolos RPC

Se debe elegir entre un protocolo orientado a la conexión o un protocolo sin conexión.

En los protocolos orientados a la conexión:

Los protocolos sin conexión tienen características opuestas a las indicadas precedentemente.

Otra opción importante es utilizar un protocolo estándar de propósito general o alguno específico para RPC.

La utilización del protocolo estándar IP (o UDP, integrado a IP) posee las siguientes ventajas:

El problema con un protocolo estándar tipo IP es el desempeño o performance: La alternativa es utilizar un protocolo especializado en RPC, que debe ser inventado, implantado, probado e insertado en los sistemas existentes: Otro aspecto importante relacionado con los protocolos es la longitud del paquete y el mensaje:


Inicio:   Fin:

Reconocimientos

Cuando los RPC de gran tamaño deben dividirse en muchos paquetes pequeños, surge la cuestión del reconocimiento:

Una estrategia de reconocimiento es el protocolo detenerse y esperar (Stop-And-Wait Protocol): Otra estrategia es el protocolo de chorro (Blast Protocol): Otra consideración más importante que el control de errores es el control del flujo: Con el protocolo detenerse y esperar no se presentan los errores de sobreejecución.

Con el protocolo de chorro pueden ocurrir errores de sobreejecución.

Una solución consiste en que el emisor inserte un retraso entre los paquetes para darle tiempo al receptor para:

Si la sobreejecución se debe a la capacidad finita del buffer en el chip de la red, el emisor puede: Un problema adicional consiste en la posible pérdida de paquetes de reconocimiento del cliente al servidor:


Inicio:   Fin:

Ruta Crítica

Es la serie de instrucciones que se ejecutan con cada RPC (ver Figura 8.10 [25, Tanenbaum]).

Ruta crítica del cliente al servidor.

Es importante determinar en qué parte de la ruta crítica se ocupa la mayor parte del tiempo que demanda la RPC:


Inicio:   Fin:

Copiado

Un aspecto que domina frecuentemente los tiempos de ejecución en RPC es el copiado.

El número de veces que se debe copiar un mensaje varía según el hardware, el software y el tipo de llamada.

En el mejor de los casos el chip de la red puede utilizar el DMA (acceso directo a la memoria) para:

Generalmente las copias efectuadas son las siguientes: El esquema precedente incluye 8 copias: Una característica del hardware que disminuye el copiado es la dispersión - asociación (scatter - gather): En los S. O. con memoria virtual se puede evitar el copiado al resguardo mediante el siguiente procedimiento:


Inicio:   Fin:

Manejo del Cronómetro

La mayoría de los protocolos inicializan un cronómetro cada vez que se envía un mensaje y se espera una respuesta.

Si la respuesta no llega en el tiempo esperado se vuelve a transmitir el mensaje.

Este proceso se puede repetir hasta un máximo previsto.

El tiempo de cpu destinado al manejo de los cronómetros puede ser considerable.

El establecimiento de un cronómetro requiere construir una estructura de datos que:

La estructura de datos de un cronómetro: Un valor de lapso de expiración muy pequeño hará que: Un valor de lapso de expiración muy grande hará que: Una alternativa al almacenamiento de los cronómetros en una tabla o lista ligada ordenada consiste en:


Inicio:   Fin:

Areas de Problemas en RPC

La RPC mediante el modelo C - S se utiliza ampliamente como base de los S. O. distribuidos [25, Tanenbaum].

Lo ideal es que la RPC sea transparente:

La mayoría de los S. O. distribuidos no cumplen totalmente con estos criterios de transparencia.

Uno de los problemas es el de las variables globales:

Un problema adicional consiste en que no siempre es posible deducir los tipos de los parámetros: Conclusión:


Inicio:   Fin:

Comunicación en Grupo

Una hipótesis subyacente e intrínseca de RPC es que la comunicación solo es entre dos partes: el cliente y el servidor [25, Tanenbaum].

A veces existen circunstancias en las que la comunicación es entre varios procesos y no solo dos (ver Figura 8.11 [25, Tanenbaum]):


Comunicación punto a punto y comunicación uno a muchos.

Un grupo es una colección de procesos que actúan juntos en cierto sistema o alguna forma determinada por el usuario.

La propiedad fundamental de todos los grupos es que cuando un mensaje se envía al propio grupo, todos los miembros del grupo lo reciben.

Se trata de una comunicación uno - muchos (un emisor, muchos receptores), que se distingue de la comunicación puntual o punto a punto (un emisor, un receptor).

Los grupos son dinámicos:

La implantación de la comunicación en grupo depende en gran medida del hardware: Las redes que no soportan multitransmisión operan con transmisión simple: Otra solución es implantar la comunicación en grupo mediante la transmisión por parte del emisor de paquetes individuales a cada uno de los miembros del grupo:


Inicio:   Fin:

Aspectos del Diseño de la Comunicación en Grupo

En la comunicación en grupo también se presentan posibilidades tales como [25, Tanenbaum]:

Además existen otras posibilidades que no se dan en la comunicación entre un emisor y un solo receptor.

Inicio:   Fin:

Grupos Cerrados Vs. Grupos Abiertos

En los grupos cerrados:

En los grupos abiertos: Los grupos cerrados se utilizan generalmente para el procesamiento paralelo: Cuando la idea de grupo pretende soportar servidores duplicados:


Inicio:   Fin:

Grupos de Compañeros Vs. Grupos Jerárquicos

En algunos grupos todos los procesos son iguales:

En otros grupos existe cierto tipo de jerarquía: Cada tipo de grupo tiene sus ventajas y desventajas: Un ej. de grupo jerárquico podría ser un programa de ajedrez en paralelo:


Inicio:   Fin:

Membresía del Grupo

La comunicación en grupo requiere cierto método para:

Una posibilidad es tener un servidor de grupos al cual enviar todas las solicitudes: Otra posibilidad es la administración distribuida de las membresías a grupos: Un aspecto problemático se presenta cuando un miembro falla, saliendo por lo tanto del grupo: Otro aspecto importante es que la entrada y salida al grupo debe sincronizarse con el envío de mensajes: Un aspecto crítico resulta cuando fallan tantas máquinas que el grupo ya no puede funcionar:


Inicio:   Fin:

Direccionamiento al Grupo

Los grupos deben poder direccionarse, al igual que los procesos.

Una forma es darle a cada grupo una dirección única, similar a una dirección de proceso.

Si la red soporta multitransmisión:

Si la red no soporta multitransmisión: Si la red no soporta multitransmisión ni transmisión simple: Un segundo método de direccionamiento de grupo consiste en pedirle al emisor una lista explícita de todos los destinos: Un tercer método es el de direccionamiento de predicados (predicate addressing):


Inicio:   Fin:

Primitivas Send y Receive

El envío de un mensaje a un grupo no se puede modelar como una llamada a un procedimiento.

Con la comunicación en grupo existen en potencia “n” respuestas diferentes y no resulta aplicable el esquema de RPC.

Se utilizan llamadas explícitas para el envío y recepción (modelo de un solo sentido).

Si se unifican las primitivas puntuales y grupales para send:

Si se fusionan las primitivas puntuales y grupales para receive: Si es necesario que las respuestas estén asociadas a solicitudes previas:


Inicio:   Fin:

Atomicidad

La mayoría de los sistemas de comunicación en grupo están diseñados para que los mensajes enviados al grupo lleguen correctamente a todos los miembros o a ninguno de ellos:

La única forma de garantizar que cada destino recibe todos sus mensajes es pedirle que envíe de regreso un reconocimiento después de recibir el mensaje: Una solución puede llegar del algoritmo de Joseph y Birman: Este algoritmo asegura que todos los procesos sobrevivientes obtendrán el mensaje, independientemente del número de máquinas que fallen o el número de paquetes perdidos.

Inicio:   Fin:

Ordenamiento de Mensajes

El ordenamiento de los mensajes es un aspecto fundamental en la comunicación en grupo.

Ej.: consideramos 5 máquinas, cada una con un proceso:

El problema es que cuando dos procesos contienden por el acceso a una LAN, el orden de envío de los mensajes no es determinista.

En el ejemplo anterior, los procesos 1 y 3 reciben los mensajes de los procesos 0 y 4 en distinto orden:

Un sistema debe tener una semántica bien definida con respecto al orden de entrega de los mensajes.

La mejor garantía es la entrega inmediata de todos los mensajes, en el orden en que fueron enviados:

Una variante al esquema anterior es el ordenamiento consistente:


Inicio:   Fin:

Grupos Traslapados

Un proceso puede ser miembro de varios grupos a la vez, pero esto puede generar un nuevo tipo de inconsistencia.

Ej.: supongamos que:

El problema es el siguiente:


Inicio:   Fin:

Escalabilidad

Es necesario considerar cómo funcionarán los algoritmos cuando se tienen los siguientes casos:

Las compuertas pueden afectar la multitransmisión y el hecho requerido por algunas redes de tener un solo paquete en la red en un instante dado.

Inicio:   Fin:
 
 

Para mayor información, seleccione una opción:

Número de visitas efectuadas desde el 17/12/2001: 
 
Estadísticas diarias desde el 10/07/2002:   Free counter and web stats  

Número de visitantes actuales disponible desde el 14/07/2002:

 

AddFreeStats.com Free Web Stats in real-time !  

 

 

Autor: lrmdavid@exa.unne.edu.ar

Ó FACENA - http://exa.unne.edu.ar

Servicios WEB: webmaster@exa.unne.edu.ar