Je to komunikační model ,implementovaný synchronizačními algoritmy,zavedený systémem ISIS řeší problém, jak spolehlivě komunikovat ve skupině, kde se dynamicky mění členství (procesy padají a obnovují se).

Řeší otázku “Co se stane, když uzel ve skupině umře?”

Synchronizace pohledů (View Synchrony Property)

Toto je definující vlastnost.

Garance: Pokud dva procesy ($p$ a $q$) přecházejí ze stejného pohledu $V_i​$ do stejného nového pohledu $V_i+1$​, musely v tom původním pohledu $V_i$​ doručit naprosto shodnou množinu zpráv.

Garance: Zpráva poslaná v pohledu Vi​ je doručena buď všem nezhavarovaným procesům v tomto pohledu, nebo nikomu.

Definuje bariéru.

Garance: Žádná zpráva odeslaná v pohledu $V_i​$ nesmí být doručena v pohledu $V_i+1​$ (a naopak).

Jde o to vytvořit pro programátora iluzi, že se věci dějí v jasných, synchronizovaných krocích, ačkoliv pod kapotou běží nespolehlivá asynchronní síť.

Zde je ten princip rozepsaný do 3 kroků, které pochopíš:

1. Koncept “view”

Systém dělí čas na tzv. views.

2. Bariéra změny pohledu (View Change)

Když někdo spadne (např. D) nebo se připojí, systém musí přejít do View_2 = {A, B, C}. Virtuální synchronie zavádí pravidlo bariéry:

3. Princip “Doruč nebo zemři” (reliability)

To nejdůležitější se děje, když odesílatel spadne uprostřed práce.

Scénář:

  1. Jsme ve View_1 {A, B, C}.
  2. Uzel A pošle zprávu.
  3. Uzel B ji přijme. Uzel C ji ještě nestihl přijmout.
  4. Uzel A spadne (Crash).

Reakce virtuální synchronie:

  1. Systém detekuje pád A. Zastaví doručování nových zpráv.
  2. Zahájí tzv. Flush protokol (Dočištění).
  3. Uzel B zjistí, že má zprávu od A, kterou C nemá.
  4. B pošle tuto zprávu uzlu C. (Přeživší si pomáhají).
  5. Teprve až mají B i C stejné zprávy, systém vyhlásí View_2 {B, C}. Image

Analogie

Představ si skupinu lidí v místnosti, kteří si dělají poznámky (replikují data).