Ora abbiamo praticamente distribuito, ma che cosa vuol dire? Che si fa?
Quando parliamo di un sistema distribuito quello che intendiamo è avere un insieme finito ognuna delle quali ha una capacità di comunicare, fare computazione, tutto allo scopo di risolvere un qualche problema (senza accezione negativa).
Per riuscire a capire se quello ha senso dobbiamo essere sicuri che sia corretto e che quindi loro tutti quanti insieme facciano quello che devono fare e che soprattutto che sia efficiente in termini di risorse ed energia.
Abbiamo più entità ognuna delle quali ha una capacità computazionali in parallelo. Ma ci sono delle differenze, abbiamo più entità in cui lavorano ma la situazioni in cui lavorano è diverso. In una macchina parallela abbiamo tipo una cpu multicores con tutti i core vicini e comunicano condividendo la memoria essenzialmente.
Nel sistema distribuito non ho una memoria condiviso, ognuno ha il suo spazio e dobbiamo considerare che potremmo essere sparsi anche in termini di territorio geografico. Cambia quindi il modo di andare ad approcciare i problemi.
Macchina parallela ≠ macchina distribuita
Nel sistema distribuito anche l’input potrebbe essere distribuito e devo capire come farli lavorare tutti quanti insieme praticamente.
Tante entità diverse, ognuna con una capacità computazionale diversa rispetto agli altri. Ciascuna ha sua memoria privata, clock, capacità computazionale che dipende dalle caratteristiche. L’unico modo per comunicare è scambiarsi i messaggi. Abbiamo però bisogno di canali di comunicazione. Queste possono avvenire solamente attraverso dei prestabiliti.
Posso usare i grafi per andare a definire la topologia del mio sistema. Quando dobbiamo risolvere un problema distribuito dobbiamo andare a capire come fare in termini di input e di problema.
Tutte quante le entità hanno lo stesso codice in realtà. Tutti devono collaborare ma partono tutti quanti dallo stesso codice e tutti devono arrivare ad avere lo stesso output. Un modo per descrivere i protocolli degli algoritmi distribuiti e che vedremo, è quello di utilizzare per ogni entità un insieme di stati possibili e di regole ed in base allo stato definire un insieme di azioni che possono essere compiute.
Gli eventi sono le cose che fanno accadere qualcosa all’interno del sistema ed in base allo stato e all’evento possono cambiare tante cose. Che cosa potrebbe far cambiare? Il clock tick, il fatto di aver ricevuto un messaggio da qualcun altro, un impulso spontaneo. Suona una sveglia → allora succede qualcosa, mi arriva un messaggio → faccio qualcosa, oppure potrei avere anche degli impulsi dall’esterno. Immagina il sistema dei bancomat, io che prelevo sono letteralmente un impulso esterno.
Che cosa succede quando una entità viene svegliata? Esegue delle azioni che vengono considerate atomiche: calcola, manda messaggio, cambia stato, cambia memoria, cambia clock, null
Queste azioni possono essere di vario tipo ma comunque devono essere una cosa finita. Come faccio a decidere che cosa devo fare? Dipendono dallo stato in cui sono e dall’evento che mi ha svegliato.
Quando descrivo un comportamento di una entità devo dire che cosa sono gli stati possibili ed in base agli eventi e allo stato in cui sono devo fare una serie di azioni.
Quello che faremo noi è descrivere il comportamento in maniera simmetrica: tutti quanti hanno lo stesso insieme di regole. Tutti le hanno uguali, ma in esecuzione possono andare a fare cose diverse in base agli input.