ciao ragazzi movimenti questo nuovo video oggi parliamo del di un protocollo finestra protocollo di comunicazione alla finestra un kobe elkann avevamo studiato quello che era lo stop and weight ok aveva studiato questo tipo di protocollo e oggi ne andiamo a studiare il go go back end ok go back end dove andremo a vedere che cosa significa questa n innanzitutto permettetemi di precisare una cosa che magari può essere utile anche nei nei video successivi e anche in questa in questa lezione la nel protocollo go back end si ha a che fare con quello che è la finestra a finestra mittente la finestra del mittente ok è in noi la chiameremo se siete d'accordo sander windows ha ris ok che è uguale a che cosa n cioè questo n sta a significare la dimensione della finestra del mittente ok poi abbiamo la finestra del ricevente ok che noi chiameremo sempre se mi permettete receiver windows size che nel caso del go back end è sempre e comunque uguale a 1 ok andiamo a cancellare questa riga età e faccia confusione allora noi dobbiamo tenere presente che tra i gobbi che nello stop weight la differenza è che il mittente a una finestra di spedizione che può avere qualsiasi tipo di valore in genere lui faremo degli esercizi con una finestra di valore pari a 4 noi faremo sempre diciamo degli esercizi per capire con un numero di n ad esempio uguale a 4 scrivere con beck an con n uguale a quattro è come scrivere go back for ok go back for significa che 4 è la dimensione della finestra del del mittente come funziona e poi andiamo a vederlo meglio l'esercizio che faremo più avanti se io ho i miei frame da spedire non importa quanti potranno essere il go back fu l'amore in questo modo spedirà 4 frame ok poi mano a mano che riceve gli hack di conferma va a spedirmi il frame successivo mano a mano che riceve un hd confermava spedirmi un altro frame mano a mano che riceve la cava spedirmi un altro frame ok questo è il funzionamento della sua finestra scorrevole il ricevente dovrà ricevere i file i frame scusate deve riceverli in ordine 0 1 2 3 4 perché non è previsto la ricezione di frame fuori sequenza nel go back n ok ricordiamoci che per quanto riguarda il go back end il sander windows size cioè la finestra del mittente deve essere per forza maggiore a1 maggiore di 1 perché perché se è uguale a 1 se n è uguale a 1 molto semplicemente stiamo parlando di scopo weight se io una finestra del mittente pari a 1 la finestra ricevente pari a 1 stiamo parlando di st.paul weight se invece io ho una finestra maggiore di uno che può essere come abbiamo detto ad esempio 4 ecco che io ho quattro frame in spedizione e il ricevente invece mantiene comunque una finestra di ricezione pari a sì perché la caratteristica principale del go back end è quella di avendo una finestra di ricezione pari a 1 è quella di accettare solamente frame in ordine non accetta frame in disordine ecco perché quando abbiamo parlato del protocollo tcp abbiamo detto che il tp può accettare segmenti in disordine dipendere dal protocollo di comunicazione in go back end non lo può fare vedremo col selective rapiti invece che le cose le cose cambiano pertanto noi adesso andiamo a cancellare qui andiamo a vedere le le cose andiamo a vedere le cose in maniera un po più specifica sperando di ricordarci un pochino tutto allora adesso andiamo a vedere quello che è uno scenario un po più preciso di come lavora il protocollo go back end abbiamo il nostro la nostra timeline ok abbiamo i nostri frame da spedire 0 1 2 3 4 5 6 7 non importa quanti la finestra del ricevente è sempre pari a 1 del protocollo go back end e quindi essendo pari a 1 il ricevente si aspetta il primo frame che è il numero zero è il mittente questo è il mittente questo è il ricevente ok ma a spedire molto semplicemente va a spedire i i primi quattro prima ok cioè 0123 ok come nel protocollo stop weight si va ad impostare quello che è il time out timer ok speriamo di starci per farvi capire bene come funziona questo e time out timer del freezer 1 2 e 3 ok che cosa succede il recente riceve il frame zero è in ordine e per cui do memorizza si sposta la finestra del ricevente e attende il frame numero uno che arriva è in sequenza e viene processato e memorizzato senza nessun problema si sposta alla finestra del ricevente e si attende il frame numero due nel frattempo cosa succede succede che sia una knowledge ment per il frame 0 sia una clone jemen per il frame 16 e la prima la finestra del del mittente era questa inizialmente una volta che ha ricevuto lac di conferma del frame numero zero la finestra si sposta in una unità e quindi mila a spedire il frame numero 4 ok aveva ricevuto anche un hack per quanto riguarda il frame numero uno per cui la finestra si sposta ulteriormente e mi va a spedire anche il frame numero 5 solo che però ad esempio giusto per capire che cosa succede succede che il fai un numero 2 non arriva il frame numero 2 non arriva ok non parte una knowledge meta non parte arriva il numero 3 poi arriva il numero 4 e poi arriva il numero 5 questi tre frame vengono semplicemente scartati perché il frame numero 3 non corrisponde a quello che il ricevente sta aspettando e lo stesso lo si può dire per il frame numero 4 e per il frame numero 5 ok per cui per cui che cosa succede per quanto riguarda il mittente succede una cosa molto semplice che siccome sta aspettando la prima o la mente del frame numero due ok che sarebbe questo a questo punto lui va a spedire l'intera finestra che per ultima era stata spedita cioè allo scadere del frame 2 che non è mai arrivato e nel quale non ha ricevuto un knowledge with va a spedire semplicemente l'intera finestra di ritrasmissione è importante capire sono stato stretto per farvi capire una cosa che adesso vi spiego bene questo sarà il frame 23 45 volevo farvi capire che quando lui ha spedito il frame 4 e il frame 5 e ha impostato il suo time out timer quando non riceve l'api knowledge and matt di un frame precedente lui va a spedire quello che è stata la dimensione dell'ultima finestra cioè questa ok 543 e due li va a spedire anche prima del del fatto che il timer vada scadere pertanto pertanto lui questo protocollo di comunicazione già in questo momento capisce che tutta questa finestra è stata scartata perché in go back end si attende solamente il frame in giusta sequenza pertanto a questo punto considerando che arrivino tutti senza nessun tipo di problema vengono tutti accettati e memorizzati uno alla volta in questo caso il frame 2 poi il ricevente si aspetta il frame 3 che arriva e viene memorizzato poi si aspetta il frame 4 che arriva e viene memorizzato poi si aspetta il frame 5 che arriva e viene memorizzato correttamente quindi è importante capire che anche prima dello scadere del time out se c'è stato un problema sulla college nate o perché non è arrivato il frame o perché non è arrivato lac knowledge maine ecco che viene rispedita l'intera finestra il fatto che si chiami go back end sta proprio a significare che si va indietro di n frame n è il dimensione della fine della dimensione della finestra se noi per ultimo avevamo spedito il frame numero 5 si va indietro in questo caso di quattro frame 5 4 3 e 2 ok e questo è il funzionamento di massima ovviamente adesso lui edimo vedere anche delle altre cose adesso noi qui abbiamo semplificato quindi il anche il discorso degli hack knowledge mente però nel protocollo go back end dobbiamo fare un discorso sugli al college mentre qui andiamo a cancellare spero che sia stato chiaro fino a questo momento ok per quanto riguarda gli hack management si possono avere due tipi di a cronologicamente siano i diack di tipo cumulativo e gli hack di tipo indipendente gli hd tipo cumulativo molto semplicemente sono quegli hack che hanno la caratteristica che ad esempio con una finestra sempre pari a 4 quindi mandiamo 4 flame ok 0 1 2 e 3 diciamo che diciamo che è poi nel passo successivo faremo un ulteriore passo per capire meglio diciamo che la risposta viene data in maniera cumulativa al mittente ok non si confermerà ogni singolo frame ma si consigliere si confermerà un insieme di frey ma ecco perché cumulativo mentre nell'apq nella knowledge ment di tipo indipendente ogni singolo frame viene riconfermato 0123 ok ogni singolo frame viene sostanzialmente riconfermato ecco perché indipendente per ogni frame sia una riconferma la differenza tra questi due tipi di hack knowledge mente è che il lac cumulativo lac knowledge mente di tipo cumulativo a meno traffico perché ovviamente si manda sostanzialmente una risposta per insieme di frame quindi c'è meno traffico ed è anche meno efficiente perché è difficile perché semplicemente se lac in risposta cumulativo si perde io devo rispedire tutti e quattro i frame nell'app di tipo indipendente invece io ho certamente è più traffico ok perché ho i frame dei dati di spedizione e opera ogni frame una clone smith però sono anche più più efficiente sono più efficiente per il semplice motivo che se una si perde io posso rispedire solamente un frame e non ho bisogno di spedire l'intera all'intera finestra allora in go back end in go back end si usa questo tipo di acne di hack knowledge mente per quanto riguarda il protocollo che vedremo successivamente che il selective répit si usa questo tipo di app management ok quindi dal su questo velo fatto vedere per farvi capire che ci sono due tipi di athlon leggermente ma per quanto riguarda il protocollo di comunicazione go back end si utilizza l'acqua di tipo cumulativo ok conti una specifica con una specifica da fare qui andiamo cancelliamo solo questo navali con una specifica da fare perché abbiamo una specifica da fare perché non è detto che però lac del tipo cumulativo vada a spedirmi un hack per una singola finestra di frame cioè non è che se io qui ho un gruppo n con n uguale a 4 cioè quindi un go back for io debba per forza spedire in ricezione e l'ac dopo aver ricevuto 4 frame questo non è assolutamente detto lo vedremo più avanti può capitare anche che nonostante la finestra del mittente sia pari a 4 ci possono essere dei casi in cui ci spediscono anche solamente due frame o un frame alla volta può capitare a fine trasmissione può capitare svariati tipi di dicasi per cui per cui in realtà non si aspetta di ricevere il numero di frame che sono impostati nella finestra del mittente del go back end in questo caso fuori si va ad aggiungere quello che è noto come un timer ok sempre considerando appunto il nostro go back for io ho quattro frame in diciamo in spedizione ok olio freiman 0123 ogni singolo frame avrà come abbiamo visto il suo time out timer questo dobbiamo saperlo 0 1 2 e 3 l'idea l'idea è quella di fare in modo di impostare un timer nel momento in cui si riceve un frame per cui nel momento in cui io ricevo il frame 0 vado ad impostare un timer questo qui ti è un uptime all ok e che cosa succede succede che in questo caso dopo che ha ricevuto il frame 0 vado ad attendere notato di tempo riceve nel frattempo anche il frame 1 ok ed ecco che io vado a spedire il mio hack di risposta ok nei quali io chiedo sostanzialmente in questo caso il frame due quindi h2o kay e la stessa cosa la farò anche per i successivi frame ok all new york times ricevo il fra il numero 2 attendo un tot di tempo nel frattempo ho ricevuto anche il 3 in questo caso ecco che allora io vado a dare una risposta e chiedo lac e chiedo il frame numero 4 quindi mando un hack numero numero 4 ok per che la cosa funzioni in maniera ottimale deve essere presente la regola che l'ac timer deve essere assolutamente minore del time out timer cioè questo timer deve essere assolutamente inferiore questo altrimenti si rischia di andare in time out timer e si rischia che il mittente de bari spedire un gran numero di frame anche inutilmente ok questo abbiamo detto succede perché non è detto che la chi no leggi menta comune di tipo cumulativo debba aspettare per forza il numero di frame della finestra del mittente focalizzazione sulla timer per quanto riguarda il go back end nel disegno che ho fatto sono stato leggermente impreciso avevamo detto che gli hack palach timer funzionava in questo modo si spediscono al mittente spedisce i suoi frame 0 1 2 e 3 sì ci sarà un certo time out timer per ogni frame ok ci sarà un certo time out timer 0123 lap timer lo avevamo giustamente che andiamo a completare bene qui ok in maniera che si capisca bene che ricevete li ricevi sta ricevendo questi frame leipheimer parte del momento in cui arriva il primo frame è dura per un tot di tempo ok è lo stesso lo farà anche nel frame successivo però quando va a rispondere la cayman l'ac primer va a rispondere nel momento in cui scade nel momento in cui scade il timer forse prima durante la spiegazione un po sono stato un po disattento lo ha segnato un po più su ma per capire che ha voluto riprendere la cosa per far capire che la parte nel momento in cui sta da il timer e farà una richiesta del frame successivo all'ultimo ricevuto in questo caso ha ricevuto lo 0 3 bizzarro ha ricevuto il frame 1 e spedirà un hack con valore 2 e qui la stessa cosa riceve il 2 aspetta un posto di tempo non fa cenno nel frattempo riceve il 3 e andrà a spedire la numero 4 in modo tale che poi il mittente potrà spedire i successivi i successivi prima ecco scusatevi per quanto riguarda questa cosa perché prima forse ero partito con la risposta della a questo punto ma non era corretto l'ac nel caso della timer parte nel momento in cui il timer scade non prima ovviamente dobbiamo parlare del dobbiamo parlare del problema del segway standard cioè oltre a svs e rvs quindi scendere windows ice receiver wind size dobbiamo parlare anche dei secoli number che è una cosa è lo chiameremo s ed è una cosa importante perché evita e il problema dei frame duplicati ok qual è il problema problema è questo ok io ho sempre il mio go back for ci sono i frame in partenza ok che arrivano tutti 0123 il mittente si aspetta lo 0 e arriva il mittente si aspetta l'uno e arriva il mittente si aspetta il 2 le arriva al mittente si aspetta il 3 e arriva arrivano tutti in ordini si va a spedire ad esempio lac si va a spedirla a che però per qualche motivo ci perde ap lost stiamo semplificando per capire che cosa succede il mittente che cosa fa lo rispedisce i frame ok non riceve a me ne del primo frame del secondo un'altra cosa fa a spedirli di nuovo 1 2 3 4 0 1 2 e 3 che cosa succede se per caso il secolo un hamburger e 4 noi qui abbiamo esaurito i nostri quattro le nostre quattro unità e per cui il ricevente ricomincerà da zero ok il secondo set di informazioni certamente ma che riparte sempre da zero in questo caso il ricevente riceve effettivamente ancora il frame 0 che però fa parte sempre dello stesso set di prima non se ne accorge lo processa e lo memorizza come buono e qui farà lo stesso lo riceve lo processano memorizza come buono e lo stesso anche per gli altri ok per poi ricominciare da zero successivamente quindi lui si ritrova qui con tutti frame che sono duplicati non sarebbe successo se il segway number invece che 4 fosse stato ad esempio 5 perché perché qui invece del numero zero cioè invece di ripartire da zero dopo 4 dopo quattro numeri consecutivi avrebbe avuto in sequenza il numero 4 in attesa ok avrebbe ricevuto il frame 0 e lo avrebbe scartato e lo stesso avrebbe funzionato anche per gli altri frame li avrebbe comunque tutti scartati avrebbe mandato un di risposta dicendo che guarda che io sto aspettando il frame 4 e lo avrebbe memorizzato quindi abbiamo bisogno di trovare un sistema tale per cui il numero di sequenza si è in grado di eliminarmi il problema dei frame duplicati come lo si risolve il problema molto semplicemente il segway number deve essere in ogni caso maggiore del sand windows size infatti avevamo visto che con una sequenza di quattro unità sia il problema dei frame duplicati con il sequel standard di 5 unità che è superiore alla fender windows ai non avremmo avuto il problema andiamo a fare un esempio andiamo a fare l'esempio cancelliamo qui andiamo a cancellare qui ok ti diamo per buono ancora il nostro disegno il sex number pari a 5 sta a significare che io attendo il fra i frame 0 poi l'uno poi il 2 poi il trend poi il 4 come quinto quindi in questo caso dopo aver ricevuto il film tra io attendo il 64 e poi ricomincerò con il secondo set cioè zero e via dicendo però attenzione che il bongo beckham si accetta un frame alla volta per cui io attendo frame 4 che cosa succede il mittente non ricevendo lac mi rimanda gli stessi frame di prima e io sostanzialmente di scarto tutti perché perché nessun frame a il numero di sequenza che mi interessa ricevere ma hanno una e dico guarda che io attendo il frame numero 4 è allora a quel punto il mittente spedirà il frame numero numero 4 che verrà processato e immesso nella sequenza solo a questo punto la finestra del ricevente può andare oltre e attendere di nuovo il frame numero zero in questo caso perché il sequestro bear era impostato a 5 quindi matematicamente matematicamente che cosa succede succede che abbiamo delle regole che valgono sempre per tutti i protocolli di comunicazione e che si possono semplificare in questo modo lo scriviamo anche qui più in grande il segway number e quindi si ha a che fare con il ricevente soprattutto diciamo che anche il anche il mittente ovviamente deve avere un sequestro amber compatibile ok ci si decide che il sequestro amber deve essere 5 in questo caso il mittente deve avere il frame 0 1 2 3 e 4 ok in modo tale che il ricevente possa organizzarsi diciamo di conseguenza e se questo bar deve essere maggiore o al tutt'al più uguale alla sander windows size più il progressivo windows size tanto è vero che se in questo caso il nostro n era uguale a 4 qui avevamo un bel 4 qui avevamo un bel 1 il cyber che deve essere maggiore o uguale a quattro più uno cioè se questi non deve essere maggiore o uguale a 5 in questo caso è infatti prima abbiamo dimostrato che con un sequestrando al pari a 4 ci possono essere problemi di freni duplicati con sai questo amber pari o superiore a 5 il problema dei frame duplicati non ci sono ora ora in realtà 5 non è un numero possibile perché perché il sempre standard viene rappresentato in vita e quindi e quindi il modo per capire quanti bit mi servono per il cyber slumber per ottenere un 6 per number compatibile è è il seguente si deve fare il logaritmo a base 2 di n più uno che in realtà appunto è questa cosa qui a questa cosa qui che cosa succede noi sappiamo che cos'è logaritmo l'abbiamo studiato abbiamo studiato voi avrete sicuramente studiato il logaritmo non è altro che l'esponente che devi dare alla base per ottenere l'argomento in questo caso in questo caso noi abbiamo il logaritmo noi abbiamo il logaritmo base 2 di 5 o quale l'esponente quale l'esponente che mi che mi risolve questo problema non è due perché altrimenti otteniamo 4 è un numero maggiore di due quindi un numero maggiore di livorno può altro che essere 3 ed era naturalmente un'approssimazione ovviamente quindi noi contraddite riusciamo ad ottenere un certo numero di sequenza che ci permette di non ottenere file duplicati questa cosa questa cosa effettivamente funziona ovviamente come ho detto prima normale per tutti i protocolli anche per lo stop and weight perché se voi andate a vedere nei libri di testo nello stop weight sia a questo tipo di lavoro si spedisce il frame 0 e si manda un hack 1 si spedisce il frame 1 e si manda un hack zero si spedisce di nuovo un frame 0 e si spedisce una 1 perché 01 01 01 perché perché nel caso dello stop weight sia il logaritmo la base 2n e la finestra del mittente che è uno più uno cioè abbiamo il logaritmo a base due di due o cioè cioè uno un beat un bit può avere valore 0 o 1 ecco che nello stop wait see a valore zero e 10 e 1 ricordiamoci un'altra cosa che nel protocollo gobbe ken n deve essere per forza maggiore di 1 perché perché se n se n è uguale a 1 questo protocollo non è altro che lo stop weight che sarebbe questo ok finestra del mittente pari a 1 finestra del ricevente pari a 1 se invece n è maggiore di 1 anche due si ha a che fare con il go back end con una sliding windows certamente ridotto ma si ha a che fare con sliding windows bene per quanto riguarda il go back end ci siamo andremo a vedere il selective ora pitt a breve ciao a tutti ragazzi