Please enable JavaScript.

Coggle requires JavaScript to display documents.

1-DNS INTRODUCTION, MOM funzionalità In ciò che abbiamo appena visto…

- - - - Comunicazione
        Permette una comunicazione facilitata tra componenti del DS eterogenei, come chiamate remote a procedura RPC, mediante RPC Client e RPC Server
        Come funziona?
        Quando eseguiamo un pagamento online con Paypal, lo shop online chiama un metodo per effettuare il pagamento, tale metodo è "locale" ma chiama una funziona presente su un altro nodo (es. Paypal).
        Come faccio a passare dati tra due entità diverse, e di cui non è detto conosca la struttura?
        Si una il Pattern Proxy, ovvero c'è un'entità di mezzo (RPC Client prima e RPC Server dopo) che prendono gli argomenti dello shop (cvc, scadenza, numero) e li mette in un marshal args, che è un formato dati comune*. Tramite ciò, i dati arrivano a RPC Server che esegue unmarshal args** ovvero prendi questi parametri e li mette in un messaggio comprensibile a Paypal (dato non comune).
      - Apertura
        Vorrei poter comunicare con altri servizi senza preoccuparmi di come siano fatti. Per fare ciò, i sistemi devono avere delle IDL Interface Definition Language ben definite, e supportare l'estensione del sistema stesso, la portabilità di applicazione e l'interoperabilità.
        Come?
        Dividendo i meccanismi dalle politiche
        esempio: browser ha meccanismo per le cache (cosa fa), separo dalla politica (come lo fa), cioè quando refresho, se è privata, per quanto tempo, quali risorse... tanti parametri!
        Possibile soluzione:
        Sistemi auto-configuranti, facenti parte dei Sistemi autonomici.
      - Scalabilità
        Essa permette di mantenere un adeguato
        livello di performance, nonostante l'aumento degli utenti, della distanza tra nodi, il numero di domini amministrativi.
        
        Size scalability, possiamo operare in verticale(scale up), cioè potenzio la risorsa,
        oppure in orizzontale(scale out), cioè aumento il numero della stessa risorsa
        
        Lo scale-up è più costoso.
        Tecniche di scaling
        
        nascondi latenza, cioè faccio comunicazione asincrona, ovvero faccio altro mentre aspetto risposta.
        
        faccio fare le operazioni all'utente
        
        partiziono dati e operazioni tra varie risorse, cioè divide et impera.
        
        replico dati e risorse, ogni nodo mantiene una copia (es Gdrive, ho una copia cache locale dei dati). Questo porta a problemi di consistenza, che dipende dal grado di tolleranza che vogliamo!
        
        Attenzione: non bisogna mai fidarsi della tecnologia, quindi non bisogna mai assumere che il network sia sicuro, omogeneo, fisso nella topologia etc...
      - Trasparenza
        Si intende un sistema unico e coerente, dove la distribuzione di processi e risorsi è trasparente/invisibile agli utenti ed alle applicazioni.
        Esistono diversi tipi di trasparenze:
        
        all'accesso : nascondo differenze sulla rappresentazione del dato e il suo accesso (come nell'esempio di prima).
        
        locazione: nascondo la locazione delle risorse, come URL fa con IP.
        
        migrazione: nascondo che una risorsa è stata trasferita, senza ridurre l'operatività.
        
        replicazione : ad esempio, youtube appare come un unico 'sito', ma presenta tante repliche!
        
        concorrenza : nascondo che le risorse potrebbero essere condivise (es su un db)
        
        fallimento : nascondo fallimento e il recupero di una risorsa.
        
        Devo rispettarle tutte?
        E' molto difficile, infatti ho problemi come:
        
        latenza, se un pc non risponde, è rotto oppure troppo lento?
        
        replica dati, è costoso mantenere copie di un dato aggiornato in ogni secondo, può creare problemi di consistenza!
- - - - Programmare con RPC
        
        NON tutti i linguaggi supportano le RPC (es C), altri parzialmente (Java da una certa versione in poi), altri totalmente (Go, Python...)
        
        Soluzioni:
        
        1) Interface Definition Language IDL, per descrivere le chiamate remote.
        
        2) Viene separato il pre-compiler che genera gli stubs.
        
        IDL
        
        Permette al programmatore di specificare le interfacce per le procedure remote
        
        Tramite IDL, il compiler può generale gli stub, marshal/unmarshal, routine di rete... è simile ad un prototipo di funzione.
        
        Funzionamento:
        In un contesto IDL + RPC, io scrivo IDL, ed invoco IDL Compiler
        (detto anche RPC compiler perchè genera automaticamente client stub, conversione dati, headers per il compiler del client (invocato da client code scritto da me) e per il compiler del server genera server skeleton, conversione dati ed headers (invocato da server code scritto da me). Headers uguali per client e server.
        
        SunRPC
        
        Richiede innanzitutto un file.x (estensione di XDR) composto da:
        
        definizione dei programmi RPC e procedure.
        
        definizione di IDL-XDR, per i tipi di dato dei parametri (se non già definiti!).
        
        Do un nome alla procedura remota appartenente ad un programma.
        Ogni procedura ha un solo parametro di input ed output. Uso le struct per ovviare a questo limite.
        
        Gli identificatori sono maiuscoli (NAME_PROG, NAME_VERS,NAME_PROC) e richiedono numero procedura (univoco), numero versione e numero del programma.
        Servono per identificare univocamente la procedura lato server.
        
        Il programmatore deve sviluppare anche il programma lato client (con il main) e lato server (procedure remote fornite dal server, ma non il main). Perchè?
        Perchè le procedure vengono invocate dal server stub che è generato automaticamente.
        
        Alcune cose importanti da sapere durante questo procedimento sono:
        
        rpcgen: con il compilatore rpcgen si generano stub client e server, oltre a degli utils per le conversioni. Esso compila square.x e genera gli stub square_clnt.c, square_svc.c, le routine XDR square_xdr.c, e l' header square.h.
        
        square.x:definizione del file.x come già detto. Serve per conoscere le procedure remote offerte dal server con i vari identificatori.
        
        server.c: Lato server non ho completa trasparenza, poichè devo specificare alcuni parametri, inoltre devo chiamare la procedura RPC col suffisso _1_svc, dove 1 è il version number.) Ad esempio avrò square_output *squareproc_1_svc(...).
        Il risultato è un puntatore ad una variabile statica, perchè il risultato deve essere accessibile anche quando de-alloco.
        
        client.c: Lato client , nel main ho clnt_create(host, SQUARE_PROG,SQUARE_VERS, "tcp")
        ometto la porta perchè ci pensa il client stub con il binding. Essa permette di gestire la comunicazione remota col server remoto.
        Devo gestire anche gli errori, e ovviamente stampare il risultato della chamata squareproc_1(&input,clnt)
        
        Sia client che server hanno la libreria <rpc/rpc.h>
        Parlo di trasparenza parziale, non parlo di socket nè di eterogeneità, ma non è totale (in quanto devo specificare alcuni parametri!)
        
        Quando avvio il server, esso pubblica i servizi. Quando avvio client, trova i servizi mediante Portmapper.
        L'hostname del Portmapper è noto, ha una porta fissa, perchè deve essere individuato dal client per poter sfruttare i servizi messi a disposizione dal server.
        
        Caratteristiche
        
        Posso avere più procedure remote, aventi differenti versioni, ma sempre con un unico input e output, utilizzati mediante azione di copy-restore.
        
        Il server garantisce mutua esclusione. Normalmente, server è sequenziale.
        
        Client fa chiamati bloccanti, aspetta la risposta, è quindi sincrono.
        
        Semantica at-least once, ritrasmetto dopo un certo intervallo. Normalmente su UDP.
        
        XDR - formato IDL
        
        E' il formato di trasferimento standard usato da Sun RPC.
        
        E' un formato binario che usa implicit typing, cioè trasmetto solo valori, non i tipi di dato.
        
        Nella prima parte del file vi definisco le costanti, ed eventualmente i tipi di dato che non sono "direttamente supportati" da XDR stesso.
        
        Nella seconda parte definisco le procedure, identificate in uppercase da nome procedura, numero di procedura, versione del numero di procedura.
        Procedura con numero 0 usato per testing.
        
        Server Binding di Sun RPC
        
        Come già detto, la procedura deve essere prima registrata dalla tripla:
        | program number | version number | procedure number |
        e dal protocollo (TCP/UDP).
        
        RPC server registra il programma su una tabella detta port map, gestita dal processo port mapper (o rpcbind, sulla porta 111) per ogni host, nella singola tupla ho:
        | program number | version number | protocol | port number | (non c'è procedure number!)
        
        Port mapper inserisce/elimina servizi, cerca porte e lista i servizi.
        
        Cosa succede nel dettaglio
        
        Lato server: il server stub crea nel main una socket e fa il binding con le porte locali disponibili.
        Chiama svc_register della libreria RPC e registra le sue procedure con port mapper (come visto prima).
        Successivamente aspetta le richieste, chiamando svc_run in risposta dei messaggi RPC.
        
        Lato client: quando lo avvio, tramite clnt_create contatto il portmapper, che mi fornisce la porta. Con questa porta contatto il processo del server. Client stub gestisce timeout e fa marshaling.
        
        Java RMI
        
        Appartiene alla seconda generazione di RPC, che supporta il linguaggio orientato agli oggetti. Utile per la distribuzione. Java RMI è un set di tools, policy e meccanismi che permettono ad una applicazione Java su un certo host di invocare metodi che girano su un altro host.
        
        Rispetto a RPC, la trasparenza è migliore, ma a livello distribuito la trasparenza non è completa.
        
        Il riferimento all'oggetto remoto è locale ed invocato mediante riferimento locale, ma l'oggetto è attivo in remoto.
        
        Ovviamente abbiamo differenze a livello di affidabilità e performance rispetto una chiamata locale!
        
        C'è una separazione tra interfacce (definizioni) e implementazioni/comportamento (classi), per permettere una separazione fisica, perchè distribuisco solo l'interfaccia, non i metodi!
        
        Stub client e server
        
        Il meccanismo è quello dei Proxy Pattern, per nascondere l'applicazione distribuita.
        
        Quando client richiede binding, lo stub == copia dell'interfaccia del server, espone la stessa interfaccia dell'oggetto remoto, viene caricata nello spazio del client. Comunica all'oggetto remoto le invocazioni.
        Il client stub effettua serializzazione.
        
        La richiesta che arriva all'oggetto remoto è gestita da un client agent == skeleton == stub server, locale al server, che effettua le chiamate ai metodi al server remoto (simulando un client locale).
        Lo Skeleton effettua deserializzazione.
        
        Grazie alla portabilità di Java, ho unico ambiente di lavoro. I proxy vengono generati in automatico, non serve rpcgen, perchè non serve IDL, ci pensa Java.
        
        Serializzazione e Marshaling
        
        nb: Posso usare SOLO oggetti serializzabili.
        Usati dai proxy per scambiare parametri input e output.
        
        Serializzazione: trasformo oggetto in sequenza di byte byte stream.
        Dipende dalla codebase presente alla destinazione.
        
        Deserializzazione: trasformo sequenza di byte nell'oggetto originale,
        ricreandolo usando il suo file .class disponibile localmente.
        
        Marshaling: eseguita da stub, converto applicazione locale in network data
        (diverso dai byte stream), inviandoli tramite pacchetti.
        
        In python sono uguali.
        
        1 more item...
- - - - Modelli di cloud
        
        Public cloud, usato dal pubblico generale mediante multi-tenancy, posseduto da un business (es Amazon) e fornito sulla sua infrastruttura.
        
        Private/enterprise cloud, usato da singola organizzazione, di solito non posseduto da essa, più sicuro (è su bassa scala), ma meno scalabile.
        
        Hybrid/Ibrido cloud, insieme dei due modelli precedenti. E' il modello più sviluppato, poichè permette di:
        
        differenziare la privacy
        
        migliorare la disponibilità (uso il public cloud in caso di disaster recovery),
        
        riduce vendor lock-in risk, cioè dipendenza dall'interfaccia di un unico provider
        
        cloud bursting, l'uso dinamico tra cloud pubblico e privato per maneggiare il carico quando il cloud privato è insufficiente, migliora le prestazioni.
        
        Tipi di servizio nel Cloud - Stack
        
        Infrastructure as a Service - Iaas
        
        Computazione, memorizzazione e rete sono servizi (quindi li usa ma non li controlla)
        
        L'utente gestisce:
        
        L'utente non gestice ma usa (indirettamente):
        
        L'utente deve fare lo scaling
        
        Amazon Web Services EC2, S3, Aruba Cloud, Microsoft Azure sono esempi.
        
        Platform as a Service - Paas
        
        L'utente può sviluppare, eseguire e gestisce applicazioni, senza la complessità dei livelli sottostanti.
        
        Il provider effettua lo scaling, non l'utente!
        
        L'utente gestisce:
        
        Esempio PaaS: AWS Elastic Beanstalk
        
        Non devo sapere nulla dell'infrastruttura (Beanstalk ad esempio configura risorse necessarie per runnare il codice).
        
        Come è fatto?
        
        Abbiamo un servizio dns fornito da Amazon, gestisce gli alias e distribuzione attraverso vari Elastic Load Balancer.
        
        Elastic Load Balancer, effettua il bilanciamento del carico di lavoro (dispatcher)
        
        Availability Zone, in cui dentro abbiamo un Auto Scaling Group composto da Istanze EC2, in cui metto le componenti della applicazioni (replicati per la scalabilità).
        
        Security Group, usato come layer dei dati per l'applicazione, non è replicato a livello logico, tutte le istanze vi accedono.
        
        NB: Se sono IaaS devo fare il provisioning delle risorse, qui lo fa Beanstalk.
        
        Software as a Service - Saas
        
        Usato dagli utenti di Internet, le applicazioni girano su infrastruttura (es Dropbox, Drive).
        
        L'utente non gestisce nulla, usa solamente.
- - - - Service Level Agreement SLA
        
        Sono contratti di qualità composti da Service Level Objectives, cioè condizioni su misure guidate da un parametro QoS.
        
        Questi parametri sono monitorati in runtime, è compito dell'utente segnalare problemi.
        
        Un criterio importante è l'uptime, misurato con la regola dei 9, che ci dice mensilmente la disponibilità di un servizio. Si usa questo parametro perchè dipende solo dal provider.
        
        Nel mondo Cloud il Service Level Objective è un predicato su un set di Service Level Indicator, ad esempio:
        uptime mensile (SLI) > 99,9% (SLO)
        
        Problematiche di Cloud SLA
        
        Misunderstanding sul "gergo" dei SLA
        
        No garanzie su tempi di riposta, dipendenti dalla rete e non controllata dal provider
        
        Difficoltà nel comparare i vari SLA, notificare violazioni o customizzare il servizio.
        
        Monitoring
        E' fondamentale per l'analisi dei dati e del servizio, viene erogata dal provider stesso o enti terzi, quasi sempre costa.
        
        Cloud Native app
        
        Utente invia richieste, distribuite da Load balancer e partizionate in base alla presenza o assenza di stato (gestione diversa).
        
        Streamalert ne è un esempio, tale applicazione si preoccupa solo di specificare la funzione da eseguire ed i dettagli tecnici, non istanzia nulla.
        
        Sviluppo di application deployment
        Processo iterativo che consiste in:
        
        deployment design, capacità di computazione, che servizi, uso Load Balancing, replico?
        
        performance evaluation, analisi delle prestazioni della nostra applicazione.
        
        deployment refinement, ovvero la parte 'feedback' del deployment dove valuto ciò che ho fatto!
        
        In che direzione stiamo andando?
        
        Poichè le applicazioni richiedono sempre più computazioni, l'idea è di usare l'offload computation ai bordi della rete (facciamo lavorare agli estremi della rete, rendendo meno esoso il carico nel 'cloud'). Diminuisce anche la latenza!
        Fog computing
        E' un modello basato su architettura a più livelli, dove trovo nodi fog (più vicini agli utenti) e cloud
        
        Fog vs Edge
        Entrambi sono decentralizzati, eseguo lo stesso incarico, in realtà sono molto simili, l'unica particolarità è che fog è più integrato col cloud (cloud nuvola, fog nuvoletta).
        Anche tra gli end-devices c'è comunque comunicazione, per definire i comportamenti corretti.
        NB: Fog/Edge evoluzione del cloud, sono DIVERSI.
        esempio fog/edge
        i devices sono automobili, il cloud dà info sullo stato del semaforo, processato dal fog. Le macchine interagiscono comunque tra di loro (anche se è verde, la macchina davanti può stare ancora ferma e quindi non posso avanzare).
- - - - Centralizzato
        
        Ho un singolo nodo che si occupa della gestione eventi, è semplice ma pecca in resilienza e scalabilità.
        
        Tipologia client server.
        
        Comunicazione basata su messaggi request/reply, le quali sono sincrone e bloccanti e fortemente interattive.
    - - Distribuito
        Si usano architetture alternative, come cluster, aumentando la complessità.
        Un'architettura content-based distribuita è più complessa di una uguale ma centralizzata.
- - - - Overlay Network
        
        Se prendiamo la collocazione dei terminali a livello di rete, e facciamo un'astrazione nella rete P2P (detta Overlay) non abbiamo gli stessi collegamenti, non c'è corrispondenza tra i layer.
        
        Questo perchè i collegamenti astratti devono ottimizzare gli HOP per il lookup (banalmente: A e B possono essere vicini, ma se hanno risorse reciproche che non servono a loro è inutile).
        
        Identificazione risorse
        
        Si usa identificatore GUID, che è hash function di alcuni metadati (o tutti) dello stato della risorsa.
        
        Anche i peer necessitano di essere identificati. Scopriremo che in alcuni casi vengono identificati attraverso le risorse possedute.
        
        Come sono organizzate queste reti?
        
        Reti non strutturate
        Basate su grafi random.
        
        :check: non essendoci una struttura, gli inserimenti/cancellazioni sono facili, O(1), e non devo mantenere una struttura che non c'è.
        
        :red_cross: il lookup delle risorse è più complessa, O(n)
        
        Caratteristiche comuni
        
        Coefficiente clustering di un vertice:
        preso vertice v, conto il numero di archi diretti tra tutti i vicini di v (senza passare per v, come se non ci fosse), e lo divido per il numero totale di archi come se il grafo fosse connesso [n*(n-1)/2], il quale essendo al denominatore va capovolto.
        
        Coefficiente clustering di un grafo : media dei valori precedenti
        
        Shortest path medio: media tra i path di due vertici.
        
        Graph diameter: il path più lungo.
        
        Esistono tre modelli principali per la creazione di questi grafi random
        
        Erdos-Renyi
        
        N: numero di vertici fissato.
        
        p: probabilità che due vertici hanno un arco
        
        p(k): probabilità che vertice v ha grado k
        
        :check: shortest path medio piccolo
        
        :red_cross: : coefficiente clustering basso (poco reale)
        
        :red_cross:Network omogeneo
        
        Watts-Strogatz
        
        E' una small world network con coefficiente clustering elevato.
        
        :check: shortest path medio corto.
        
        :check: coefficiente clustering alto indipendente dal numero dei vertici.
        
        :red_cross: Non contempla la presenza di nodi influencer
        
        Fenomeno Small world
        
        Presi due individui random nel mondo, esiste un path massimo di 6 hop che li collega.
        
        Albert-Barabasi
        
        E' uno scale free network, cioè segue la legge di potenza, che mostra come le code siano spesse (ovvero mediana > media).
        con 2 < a < 3
        
        Invarianza della scala : prendo il grafico, faccio uno zoom su una sezione, la sezione zommata è uguale al grafico non zommato (inception).
        
        Come si legano i nodi tra loro?
        
        Un nodo con molte connessioni tende ad attirare altre connessioni.
        
        Il diametro del grafo è ln (ln N), sempre dipendente da scale free.
        
        Ciò comporta anche alta resilienza e resistenza ai guasti.
        
        Strutturati
        
        L'obiettivo è migliorare la scalabilità diminuendo i costi di lookup. Mantenere la struttura comporta però un dispendio maggiore nel mantenimento della stessa (aggiungi nodo, togli nodo etc).
        
        Concetti base
        
        Ogni peer è responsabile di alcune risorse, inoltre conosce i suoi vicini nell'overlay structure.
        
        Ogni risorsa e peer ha associato un GUID, ottenuto tramite Hash. Lo spazio di indirizzamento (l'identificativo) è usato sia per peer che per risorse (il peer è identificato dalle risorse che ha).
        
        Routing basato su Distributed Hash Table DHT
        
        Distributed Hash Table
        
        E' semplicemente la versione distribuita delle Hash Table.
        
        Ho una tabella di tuple (chiave,valore) di dimensione M (dette bucket).
        
        Il mapping va fatto nei bucket da 0 a M-1 (veloce, ma possono esserci collisioni).
        
        Nella DTH si cercano i bucket contenti la risorsa, che però sono spartite attraverso nodi/peer multipli (bucket == peer)
        
        Funzionamento specifico
        
        Il funzionamento si basa su tuple (chiave K, valore V). Ogni riga = tupla può essere associata a bucket == peers diversi.
        Un'applicazione distribuita vuole trovare un certo valore, esegue Hash(metadati del valore) = GUID = chiave K, nella DHT si cerca questa chiave primaria, trovo la coppia <k,v> dove k indentifica la risorsa contenuta in V. Quindi trovata questa coppia so quale è il nodo che la possiede.
        
        Come vi accedo?
        
        V = get(K), ottengo V associato a K, lo prendo dall'applicazione distribuita.
        
        put(K,V): memorizzo risorsa V identificata da K nel nodo responsabile della risorsa nella hash table condivisa.
        
        remove(K): elimina riferimento K a V dall'applicazione distribuita.
        
        Come progettare una DHT?
        
        Nodi e risorse vengono mappate su stesso spazio di indirizzamento.
        
        Ogni nodo ha associata una porzione contigua di chiavi e memorizza info su risorse mappate sulla sua chiave.
        
        Data K, mappo cercando il GUID più vicino a K.
        
        Difetti/Svantaggi :red_cross:
        
        Devo evitare la presenza di nodi che gestiscono più dati rispetto agli altri, non voglio quindi nodi più importanti di altri.
        
        Quando ho in/out di nodi, devo gestire la struttura, riassegnando anche le chiavi in modo da non impattare troppo il sistema. Consistent Hashing è la soluzione a questo problema.
        (leggasi: devo toccare poco la struttura).
        
        DHT basata su exact-match, devo conoscere la chiave, quindi no query complesse o range di chiavi.
        
        ... più nel dettaglio...
        
        Pro :check:
        
        ottimo per ricerca su sistemi estesi P2P
        
        decentralizzato (no single server)
        
        hashing consistente ed elegante
        
        scalabilità incrementale
        
        replicazione fault tolerance
        richiede configurazione minima
        
        Contro :red_cross:
        
        soffre guasti bizantini
        
        nodi in/out in O(log N) non è proprio il top!
        
        ha un pò "deluso" le aspettative.
        
        P2P basati su DHT
        
        Hanno alta scalabilità rispetto la size.
        
        Esistono diversi modelli che si differenziano per gestione GUID o comunicazione tra peer.
        
        Tra i più noti annoveriamo Pastry e Chord, quest'ultimo è di nostro interesse.
        
        1 more item...
- - - - At-least-once semantica
        
        Il servizio viene eseguito almeno una volta.
        
        Richiede unicamente RR1, non ci importa dei duplicati. Va bene per operazioni idempotenti (stessa op più volte, stesso risultato).
        
        Client non sa nulla dello stato del server (quante volte ha eseguito l'operazione?), solo quando riceve una risposta sa che almeno una volta l'operazione è stata processata.
        
        Normalmente è la più usata, ma solo perchè è il "minore dei mali", abbiamo sempre un tradeoff!
      - May-be semantica
        
        Non ho garanzie se l'operazione è stata eseguita o meno dal server, non uso alcun meccanismo. E' come UDP.
      - Exactly-once semantica
        
        E' la più restringente ma anche la più difficile da implementare, per questo poco usata.
        
        E' basato su all or nothing, quindi se tutto va bene il server esegue solo una volta, trovando i duplicati. Se qualche cosa non va bene, riesco comunque a capire se il server è run o meno, perchè un requisito di questa semantica è la piena interazione, che quindi comporta il conoscere lo stato dell'altro.
        
        Si usano i tre meccanismi, ma non bastano!
        
        Vengono introdotti:
        
        Replicazione trasparente del server: non distinguo tra server reale e copia, in modo da non vedere se crasha.
        
        Write Ahead loggin WAL: detto commit log, con il compito di mantenere la lista delle operazioni eseguite, memorizzandole prima dell'esecuzione (altrimenti, se fallissero, le perderei). Questo file è leggibile ad ogni restart, per rieseguire le operazioni e tornare in uno stato consistente.
        
        Recovery: mediante snapshot distribuito (foto dello stato attuale) e checkpointing (riparto da uno stato sicuro per poi tornare nella condizione di snapshot).
      - At-most-once semantica
        
        Operazione eseguita al massimo una volta,
        il client quando riceve il reply sa che il server ha eseguito al massimo una volta. Senza reply non ho informazioni!.
        
        Si usano tutti e tre i meccanismi:
        RR1 se server non risponde, DF e RR2 perchè il server mantiene stato (un log) per identificare richieste duplicate.
        Ciò è possibile grazie a Id unico (xid) messo nelle richieste, il server vede se è una vecchia richiesta (e allora usa il risultato già calcolato) o una nuova richiesta (allora la computa e la mantiene in caso di richieste duplicate future).
        Quanto mantenere questi dati?
        Dipende dal meccanismo: si può usare un lifetime o sliding windows.
        
        Va bene per servizi idempotenti e non, visto che c'è questo filtraggio.
        
        Client e Server non coordinati, nel senso che in caso di errore non so quale sia questo errore!
- - - - Esempi di sistemi Message Oriented Middleware: KAFKA
        
        Sistema Pub/Sub general purpose. Kafka è architettura distribuita composta da molteplici server detti broker.
        
        Sfrutta il concetto di topic, a cui possono iscriversi 0,1 N consumers, che si devono iscrivere.
        
        Topic: categoria in cui viene pubblicato il messaggio. Per ogni topic si ha un log partizionato, struttura dati in cui gli elementi si aggiungono solo in coda.
        
        Il topic viene diviso in partizioni, o unità di parallelismo.
        
        La singola partizione è composta da record, il singolo record è identificato da un offset (che funge anche da ID), permettendo accessi in parallelo su record diversi della stessa partizione. La singola partizione è ordinata temporalmente ed immutabile (aggiungo solo in coda). L'ordine non vale considerano globalmente le partizioni.
        La pubblicazione dei record avviene mediante round robin o partizionamento per chiave.
        
        I broker gestiscono questi topic (poichè gestiscono le partizioni distribuite), i quali devono anche ricevere e memorizzare i dati.
        
        Ogni partizione è replicabile su broker diversi detti Follower, mentre il principale è detto Leader). Esiste Replication factor = x, cioè esiste 1 leader e x-1 copie. Un consumer crashato può recuperare msg dai topic.
        
        Ogni partizione ha un leader, che gestisce letture/scritture. Solo se esso crasha se ne sceglie un altro.
        
        Non esiste un broker leader di tutto, al massimo leader di una partizione e follower di altre.
        
        Produttori: pubblicano data a seconda del topic specificato, inviandoli direttamente al broker leader della partizione. I producer inoltre sono responsabili di scegliere partizione del topic (in base alla chiave o round robin). (nb: io produco, io scelgo dove mandarlo). Posso avere più produttori che scrivono su stessa partizione (non stesso record), sempre in modo ordinato.
        
        Consumatori: posso scegliere per loro due modelli:
        
        Push Model: Broker fa push dei messaggi (li spinge verso consumer), quindi è il broker che deve gestire l'eterogeneità dei dati, cioè adattarsi.
        
        Pull Model: usato da Kafka, tutta la complessità di prima è reindirizzata verso i consumatori, è il consumer che deve prelevare i messaggi dal broker. E' sicuramente più scalabile (broker più semplice) ma può portare il consumer a perdere troppo tempo per vedere l'arrivo di messaggi.
        In particolare, quando consumer legge un messaggio, salva il suo offset in un topic speciale chiamato __consumer_offset (istanziato automaticamente da Kafka). Se consumer crasha, può reperire da qui l'offset da cui ripartire.
        
        Consumer Group: insieme di consumer che cooperano per consumare dati da topics, identificati da un ID di gruppo. I partizionamenti sono divisi tra questi consumer nel gruppo per bilanciare il carico. Ogni messaggio è consegnato solo ad un elemento del gruppo. Ogni gruppo mantiene gli offset delle partizioni.
        L'idea fondamentale è vedere più consumer come unica entità. Se volessi due consumer che leggono stesso messaggio, i due consumer devono appartenere a gruppi diversi! (poichè messaggio consegnato ad un solo elemento del gruppo!)
        
        Delivery semantics
        
        At least once: predefinita, non perdo messaggi, non ho certezza dell'ordine (se leggo da partizioni diverse).
        
        Exactly once: non proprio come l'abbiamo già vista, richiede risorse più complesse (Two face commit).
        
        E' possibile, gestendo alcuni aspetti, ottenere sematica At most once.
        Fault tolerance
        
        Kafka esegue replicazione delle partizioni, rendendo messaggio disponibile solo dopo che tutti i follower hanno terminato la scrittura ed hanno fatto ack al leader di partizione, quindi messaggi possono non essere subito disponibili, priorità alla consistenza piuttosto che alla disponibilità. E' un tradeoff. I messaggi vengono mantenuti per un tot di tempo, compattandoli per ridurre spazio.
        
        ZooKeeper
        
        Progetto opensource, gerarchico, basato su chiave valore.
        
        Usato da Kafka per coordinare produttori. Zookeeper memorizza i metadati di Kafka di , consumatori e brokers, ed elegge i leader.
        
        Zookeeper mantiene una variabile di stato 0/1 a seconda se il follower di un leader è non attivo/attivo. Questa info serve al leader per l'attività di memorizzazione.
        :red_cross: l'unico problema di Zookeeper è che si tratta di un qualcosa di esterno che occupa risorse, mentre sarebbe ideale un qualcosa di interno.
        
        KRaft
        
        Alternativa a Zookeeper per la gestione di metadati e consensi. Questa volta i metadati sono gestiti direttamente in Kafka, con un protocollo di consensi.
        
        Ad esempio, con ZooKeeper il quorum per scegliere era esterno, adesso è interno, tra le istanze candidate stesse.
        
        API di Kafka
        
        Producer API: pubblico record di un topic.
        
        Consumer API: leggo record di un topic.
        
        Connect API: permette l'uso di connettori riusabli per collegare i topic di Kafka con app o data systems. Poco usata perchè esistono già tanti connettori disponibili.
        
        Streams API: trasformo streams di dati da input topic ad output topic.
        
        Protocolli per MOM
        
        Fino ad ora abbiamo visto sistemi, ma possiamo parlare anche di protocolli per code di messaggi.
        
        Basati su standard aperti, obiettivo comune è fornire soluzioni di messaggistica indipendenti dalla piattaforma o dal vendor ed offrono interoperabilità fra di versi sistemi MOM.
        
        Spesso usati nell’IoT: usati per mandare dati da sensori verso broker di messaggistica che poi li invia a framework per farli processare. Sfruttano i vantaggi dei sistemi MOM:
        
        disaccoppiamento
        
        resilienza: ho uno storage di dati temporaneo.
        
        gestione dei picchi di traffico: dati persistenti in MOM e processati in secondo momento.
        
        Vediamo un esempio di protocollo MOM
        
        AMQP
        
        Standardizzato nel 2014, di tipo binario, è un protocollo di livello applicativo basato su TCP con meccanismi at most once, at least once, exactly once delivery.
        
        E' programmabile, cioè diverse entità sono configurabili.
        
        Implementato in diversi sistemi/framework, tra i quali RabbitMQ.
        
        Modello di AMQP
        
        Abbiamo Publishers, Brokers e Subscribers.
        
        I producers pubblicano i messaggi su una Exchange, facente parte dell'AMQP Broker.
        
        Il Broker, mediante questo meccanismo di Exchange, instrada (fa route) dei messaggi verso le rispettive code, mediante binding (cioè regole di instradamento). Il Binding può essere:
        
        direct exchange: instrado basandomi sulla chiave del messaggio.
        
        fanout exchange: simil broadcast, inoltro su tutte le cose a cui sono collegato.
        
        topic exchange: instrado basandomi sul topic. E' una via di mezzo tra i primi due, perchè posso inviare a più consumer che sono interessati a quel topic.
        
        header exchange: instrado basandomi su vari attributi specificati nell'header, che magari risultano più facili da definire rispetto al routing basato su chiave.
        
        La lettura dei messaggi dei Subscribers dipende dall'implementazione, AMQP supporta sia pull che push.
        (in RabbitMQ push, in Kafka pull))
        
        Messaggi in AMQP
        
        Possiamo definire due tipi di messaggi:
        
        Bare message: messaggi dei producer (il messaggio vero e proprio).
        
        Annotated message: bare message + info intermedie aggiunte durante il trasporto (header con timetolive e priority, footer...)
        
        1 more item...
- - - - Protocolli di gossiping
        
        Fino ad ora abbiamo visto gli algoritmi, i quali sono utilizzati dai protocolli.
        
        Blind counter rumor mongering
        
        Il nome deriva da:
        
        blind: Un nodo che diffonde l’informazione perde interesse a diffonderla, non importa quanto sia rilevante.
        
        counter: Dopo tot contatti, termina la trasmissione dell’informazione.
        
        rumor mongering: diffonde il gossip.
        
        Dipende da due parametri:
        
        B: numero di nodi a cui comunico il gossip.
        
        F: numero di nodi che contatto prima di stancarmi.
        
        Funzionamento:
        
        Invio: Un nodo n inizia il broadcast, inviando a B nodi vicini, scelti casualmente, il messaggio m.
        
        Ricezione: Il nodo p riceve messaggio m da nodo q. Il nodo p si chiede quante volte ha già ricevuto questo stesso messaggio m.
        
        Se lo ha ricevuto meno di F volte, trova B vicini scelti casualmente ed inoltra m, ma questi nodi non devono averlo mai visto. Come li riconosco? Sono i nodi a cui ho già mandato m in precedenza, e i nodi che hanno mandato a me il messaggio m.
        
        Altrimenti si stanca e non propaga.
        
        Performance
        
        Difficile descriverlo analiticamente, si fa ricordo a simulazioni.
        
        Bimodal multicast
        
        Detto anche pbcast, perchè rende probabilistico un algoritmo non tollerante ai guasti.
        
        Presenta due fasi:
        
        Message distribution: un processo manda msg in multicast, senza particolari garanzie. Se nodo inviante crasha, o se nodo ricevente crasha, non ho meccanismi di garanzia.
        Questa prima fase è molto rapida, ma senza garanzie.
        
        Gossip repair: fase successiva, quando il processo riceve messaggio, inizia a fare gossip su questo messaggio con altri peer, non tutti, perchè è probabilistico). Avviene periodicamente, su intervalli di tempo regolari. Il gossiping sul messaggio viene fatto scambiando dei digest, che descrivono lo stato, ma non include il messaggio. Chi riceve questo digest, lo confronta col proprio storico. Se c'è qualche differenza, sollecita per avere le copie dei messaggi che non ha ricevuto. Successivamente vengono ritrasmesse queste copie, cioè i messaggi richiesti.
        
        Perchè bimodale?
        
        1) Perchè con probabilità elevata posso riscontrare due esiti:
        
        messaggio consegnato a tutti.
        
        messaggio consegnato a nessuno (il sender crasha).
        I casi di mezzo sono meno probabili.
        
        2) motivi di latenza, posso infatti:
        
        ricevere subito il messaggio con bassa latenza, se lo ricevo direttamente dal server.
        
        riceverlo dopo più fasi di gossip repair, e quindi latenza aumenta ad ogni fase.