Arquitectura cotilla

En este proceso se distinguen las siguientes fases: Como ya sabemos, en la arquitectura cotilla (gossip) los front-end (FE) envían "queries" y "update" a un replica manager (RM) seleccionado, además garantiza que cada cliente obtiene un servicio con integridad en el tiempo y entre las réplicas.

Bajo estas circunstancias el trafico se reduce ya que las réplicas de solo lecuta no propagan mensajes "gossip" y los vectores de tiempo solo necesitan contener entradas para las réplicas actualizadas.

El frontal adjunta prev, que contiene una entrada por cada gestor, a cada mensaje de petición a un gestor, junto con el tipo de petición (update o query).

Cuando un gestor devuelve un valor como resultado de una consulta, proporciona a su vez un nuevo vector de marcas temporales (new), debido a que es posible que las réplicas hayan sido actualizadas desde la última operación.

Los clientes intercambian información accediendo al mismo servicio cotilla y comunicándose directamente entre sí.

Ilustración 1: Operaciones de consulta y actualización en un servicio cotilla
Ilustración 2: Los frontales propagan sus marcas temporales cuando los clientes se comunican de manera directa
Ilustración 1: Operaciones de consulta y actualización