1
00:00:07,980 --> 00:00:12,560
 Nell'ultimo video, abbiamo esaminato
 in modo molto dettagliato il processo

2
00:00:12,560 --> 00:00:16,460
 viene utilizzato quando creiamo l'albero
 condiviso, come l'appartenenza a IGMPM

3
00:00:16,460 --> 00:00:21,780
 il report ricevuto dal gateway predefinito
 avvia un PIM, quello che chiamiamo star,

4
00:00:21,780 --> 00:00:27,420
 G-join, che procede hop dopo hop
 fino al punto di incontro.

5
00:00:27,420 --> 00:00:31,940
 E abbiamo visto come ciÃ² accade, ogni
 router dal router, quello predefinito

6
00:00:31,940 --> 00:00:35,260
 gateway che ha ricevuto il rapporto
 di adesione e quindi ciascun router

7
00:00:35,260 --> 00:00:39,740
 il percorso che riceve la stella, congiungimento
 G fino al punto d'incontro,

8
00:00:39,740 --> 00:00:44,440
 che ha creato quello che abbiamo chiamato stella, stato
 del percorso G-em nel nostro routing multicast

9
00:00:44,440 --> 00:00:55,380
 tavolo. Quindi una volta che abbiamo quella stella,
 lo stato del percorso G-em, che Ã¨, non lo faccio

10
00:00:55,380 --> 00:00:59,080
 importa quale sia la fonte, una volta che
 inizia a raggiungere il punto di incontro,

11
00:00:59,080 --> 00:01:03,420
 abbiamo una connessione aperta, un percorso
 aperto, fino al ricevitore.

12
00:01:03,420 --> 00:01:06,820
 E questo si basa su ciÃ² che Ã¨ stato mostrato
 nell'elenco delle interfacce in uscita.

13
00:01:06,820 --> 00:01:13,180
 Ok, ora iniziamo effettivamente il multicast
 e vediamo cosa succede lÃ¬.

14
00:01:13,180 --> 00:01:19,800
 Quindi la linea tratteggiata verde in questo
 caso particolare indica l'albero condiviso

15
00:01:19,800 --> 00:01:21,140
 quello Ã¨ giÃ  aperto.

16
00:01:21,140 --> 00:01:26,180
 Ora non sto mostrando R8 qui, ma
 sappiamo che R8 Ã¨ tra questi due.

17
00:01:26,180 --> 00:01:30,160
 Ora la fonte inizierÃ .

18
00:01:30,160 --> 00:01:34,700
 E quello che vedremo Ã¨ quando R4
 riceverÃ  il multicast nativo

19
00:01:34,700 --> 00:01:39,840
 pacchetti dalla fonte, dirÃ ,
 eh, ho un problema qui.

20
00:01:39,840 --> 00:01:46,820
 PerchÃ© mi Ã¨ consentito inoltrare questi
 pacchetti multicast nativi solo se

21
00:01:46,820 --> 00:01:51,820
 Ho alcune voci nella mia tabella di routing
 M che hanno un'interfaccia in uscita

22
00:01:51,820 --> 00:01:56,960
 elenco delle interfacce. Ma dirÃ 
 che nessuno me lo ha mai chiesto.

23
00:01:56,960 --> 00:02:00,140
 Non ho mai ricevuto alcun rapporto
 sull'adesione all'IGMP.

24
00:02:00,140 --> 00:02:03,060
 Non ho mai ricevuto alcuna
 adesione PIM da nessuno.

25
00:02:03,060 --> 00:02:05,820
 Quindi non ho un posto dove inviarlo.

26
00:02:05,820 --> 00:02:08,140
 Eppure potrebbero esserci
 dei ricevitori lÃ  fuori.

27
00:02:08,140 --> 00:02:09,600
 Allora cosa faccio?

28
00:02:09,600 --> 00:02:12,940
 Bene, con la modalitÃ  sparsa PIM,
 quello che farÃ  Ã¨ prendere

29
00:02:12,940 --> 00:02:19,280
 quel pacchetto multicast e lo incapsulerÃ 
 all'interno di un unicast.

30
00:02:19,280 --> 00:02:22,520
 E questo sarÃ  all'interno
 di un pacchetto PIM.

31
00:02:22,520 --> 00:02:27,300
 Quindi ci sarÃ  un altro tipo di pacchetto
 PIM chiamato registro PIM.

32
00:02:27,300 --> 00:02:29,120
 Ed Ã¨ quello che vedremo in seguito.

33
00:02:29,120 --> 00:02:31,640
 Quindi il registro PIM
 effettivamente porta.

34
00:02:31,640 --> 00:02:36,600
 Ã un pacchetto unicast, unicast
 da R4 direttamente all'RP.

35
00:02:36,600 --> 00:02:39,200
 Quindi vedremo gli indirizzi sorgente R4.

36
00:02:39,200 --> 00:02:42,240
 L'indirizzo di destinazione
 Ã¨ il punto d'incontro.

37
00:02:42,240 --> 00:02:45,920
 Il tipo PIM sarÃ  un nuovo
 tipo chiamato registro.

38
00:02:45,920 --> 00:02:51,240
 E nel corpo ci saranno effettivamente
 i nostri dati multicast.

39
00:02:51,240 --> 00:02:55,840
 E quando il punto d'incontro lo avrÃ 
 capito, lo deincapsulerÃ , rivelandolo

40
00:02:55,840 --> 00:02:57,780
 il pacchetto multicast.

41
00:02:57,780 --> 00:03:01,840
 E poi l'RP dirÃ , okay, ho
 uno stato per questo?

42
00:03:01,840 --> 00:03:04,020
 Qualcuno me lo ha mai chiesto?

43
00:03:04,020 --> 00:03:07,200
 Bene, in questo caso dirai di sÃ¬, perchÃ©
 il nostro albero condiviso esiste giÃ 

44
00:03:07,200 --> 00:03:08,740
 pronto e in attesa.

45
00:03:08,740 --> 00:03:11,460
 Quindi lo inoltrerÃ  lungo
 l'albero condiviso.

46
00:03:11,460 --> 00:03:15,220
 Ecco come inizierÃ  inizialmente il
 nostro multicast registrando questo

47
00:03:15,220 --> 00:03:26,920
 modo. Quindi ora ciÃ² potrebbe continuare
 potenzialmente indefinitamente.

48
00:03:26,920 --> 00:03:28,600
 Giusto? Voglio dire, funziona.

49
00:03:28,600 --> 00:03:31,640
 Ottiene il multicast dalla
 sorgente al ricevitore.

50
00:03:31,640 --> 00:03:38,240
 Ma chiede al router connesso alla
 sorgente e all'RP di funzionare

51
00:03:38,240 --> 00:03:42,940
 un po' piÃ¹ difficile avvolgere questa
 cosa in un unicast e scartarla

52
00:03:42,940 --> 00:03:45,360
 dall'unicast dall'altra parte.

53
00:03:45,360 --> 00:03:50,440
 Quindi, anche se funziona, consuma
 un po' piÃ¹ di risorse della CPU.

54
00:03:50,440 --> 00:03:54,040
 E certamente se avessimo dozzine o centinaia
 di flussi multicast in esecuzione

55
00:03:54,040 --> 00:04:05,320
 questo, potrebbe potenzialmente essere negativo
 per l'RP che Ã¨ multicast all'interno.

56
00:04:05,320 --> 00:04:08,500
 Quindi cosa succederÃ ?

57
00:04:08,500 --> 00:04:13,940
 E lo vedremo nel prossimo segmento in modo piÃ¹
 dettagliato, quando ci sarÃ  l'appuntamento

58
00:04:13,940 --> 00:04:18,400
 Se il punto riceve questo pacchetto di
 registro pin, in realtÃ  ne farÃ  un paio

59
00:04:18,400 --> 00:04:20,260
 delle cose contemporaneamente.

60
00:04:20,260 --> 00:04:23,640
 Numero uno, lo scarterÃ  e lo inoltrerÃ 
 lungo l'albero condiviso.

61
00:04:23,640 --> 00:04:25,320
 Ne abbiamo giÃ  parlato.

62
00:04:25,320 --> 00:04:36,140
 La prossima cosa che il punto d'incontro Ã¨ questo
 multicast nella sua forma nativa pura.

63
00:04:36,140 --> 00:04:38,600
 Quindi posso semplicemente inoltrarlo
 in base al mio percorso M.

64
00:04:38,600 --> 00:04:41,700
 Quindi non devo continuare a tormentare
 la mia CPU con esso.

65
00:04:41,700 --> 00:04:43,000
 Vedi, come posso farlo?

66
00:04:43,000 --> 00:04:46,540
 Bene, so che il mio vicino
 a monte lo inoltrerÃ  solo a

67
00:04:46,540 --> 00:04:48,980
 me se glielo chiedo.

68
00:04:48,980 --> 00:04:53,160
 Quindi l'RP invierÃ  effettivamente un
 messaggio di adesione al suo vicino.

69
00:04:53,160 --> 00:04:57,560
 Ma questa non Ã¨ una commedia da star
 perchÃ© in realtÃ  conosce la fonte.

70
00:04:57,560 --> 00:05:01,040
 Quando arriva il primo multicast,
 dice, oh, so chi Ã¨ la fonte

71
00:05:01,040 --> 00:05:07,240
 Ã¨, 4.5.4.5. Quindi invierÃ  quello
 che viene chiamato un join S, G.

72
00:05:07,240 --> 00:05:11,280
 Quando vediamo nella traccia dello snipper, Ã¨
 esattamente lo stesso formato di una stella

73
00:05:11,280 --> 00:05:15,600
 -comedy join, tranne che elenca
 l'indirizzo di origine e un paio

74
00:05:15,600 --> 00:05:17,800
 anche le bandiere sono diverse.

75
00:05:17,800 --> 00:05:24,440
 E questo apre l'albero del percorso
 piÃ¹ breve dal punto d'incontro a

76
00:05:24,440 --> 00:05:29,120
 la fonte. PerchÃ© ricorda, abbiamo parlato
 di come esiste potenzialmente

77
00:05:29,120 --> 00:05:32,080
 piÃ¹ alberi condivisi, giusto?

78
00:05:32,080 --> 00:05:35,240
 Se sono un punto d'incontro e ci
 sono 50 ricevitori diversi sparsi

79
00:05:35,240 --> 00:05:38,940
 attraverso la rete potrebbero esserci
 50 diversi alberi condivisi.

80
00:05:38,940 --> 00:05:44,020
 Ebbene, allo stesso modo, il concetto di albero
 del percorso piÃ¹ breve proviene da un individuo

81
00:05:44,020 --> 00:05:45,880
 punto di vista del router.

82
00:05:45,880 --> 00:05:49,700
 Il mio percorso piÃ¹ breve per arrivare a quella
 fonte Ã¨ che un router potrebbe essere diverso

83
00:05:49,700 --> 00:05:54,700
 del percorso piÃ¹ breve per
 arrivare alla stessa fonte.

84
00:05:54,700 --> 00:05:57,360
 Quindi il punto d'incontro, quando riceverÃ 
 questa busta di registrazione, se ne andrÃ 

85
00:05:57,360 --> 00:06:02,820
 per dire, voglio aprire il mio percorso
 piÃ¹ breve per arrivare a quella fonte.

86
00:06:02,820 --> 00:06:06,140
 PerchÃ© una volta aperto, questi
 registri si fermeranno.

87
00:06:06,140 --> 00:06:09,900
 InizierÃ² a ottenere il multicast
 puro nella sua forma nativa.

88
00:06:09,900 --> 00:06:15,180
 Quindi non appena arriva il
 registro, oltre a inoltrarlo

89
00:06:15,180 --> 00:06:23,900
 in questo modo, questo RP verrÃ  inviato,
 lasciami espandere un po', lo Ã¨

90
00:06:23,900 --> 00:06:34,200
 invierÃ² una s, G si unirÃ  a monte.

91
00:06:34,200 --> 00:06:39,960
 E questo, in R4, aggiungerÃ  il segno elettronico
 veloce a zero, zero nel suo

92
00:06:39,960 --> 00:06:42,320
 elenco delle interfacce in uscita.

93
00:06:42,320 --> 00:06:45,600
 Ora i nostri quattro diranno:
 Oh, fantastico.

94
00:06:45,600 --> 00:06:50,200
 Ok, ora posso iniziare a inoltrare il multicast
 downstream nella sua forma pura

95
00:06:50,200 --> 00:06:55,180
 forma nativa. Ma indovina un po',
 continuerÃ  a registrarsi.

96
00:06:55,180 --> 00:06:59,540
 Quindi ora otterremo due copie di questi
 pacchetti multicast sul file

97
00:06:59,540 --> 00:07:03,400
 RP. Metteremo in funzione
 il multicast nativo.

98
00:07:03,400 --> 00:07:08,560
 E ne otterremo un'altra copia all'interno
 di questo pacchetto di registro pin.

99
00:07:08,560 --> 00:07:14,380
 Ora potresti dire: perchÃ© Ã¨ successo?

100
00:07:14,380 --> 00:07:18,360
 PerchÃ© una R4 si ferma a quel punto?

101
00:07:18,360 --> 00:07:20,600
 Bene, ecco perchÃ©.

102
00:07:20,600 --> 00:07:24,600
 In questa particolare topologia,
 non la descrive molto bene.

103
00:07:24,600 --> 00:07:40,480
 Ma immagina se avessi questo.

104
00:07:40,480 --> 00:07:44,140
 Ok, quindi immagina se,
 sai, ecco la mia fonte.

105
00:07:44,140 --> 00:08:00,640
 Ok, abbiamo il router
 X e abbiamo il PIM RP.

106
00:08:00,640 --> 00:08:02,740
 E questo Ã¨ il router cinque.

107
00:08:02,740 --> 00:08:08,800
 Ok, quindi qui la mia fonte sta inviando
 il suo multicast al router cinque.

108
00:08:08,800 --> 00:08:13,700
 Il router cinque prende quindi
 il multicast e lo registra.

109
00:08:13,700 --> 00:08:20,020
 Vedi se riesco a disegnare
 qualcosa qui per indicarlo.

110
00:08:20,020 --> 00:08:23,060
 Quindi questa Ã¨ la registrazione.

111
00:08:23,060 --> 00:08:34,020
 E ora il router cinque
 ottiene un join s, g.

112
00:08:34,020 --> 00:08:38,940
 Quindi la fonte Ã¨, vediamo qui,
 qual Ã¨ la fonte del ragazzo?

113
00:08:38,940 --> 00:08:41,740
 4.5.4.5 nel mio esempio particolare.

114
00:08:41,740 --> 00:08:45,280
 Quindi dice, okay, ecco
 un'adesione al PIM.

115
00:08:45,280 --> 00:08:51,320
 E in realtÃ  elencherÃ 
 la fonte e il gruppo.

116
00:08:51,320 --> 00:09:06,140
 Ok, beh, quando arriva questa cosa,
 se ci fosse, come posso esprimerla?

117
00:09:06,140 --> 00:09:08,960
 In realtÃ , ecco un esempio migliore.

118
00:09:08,960 --> 00:09:16,180
 Metti un router proprio qui al centro.

119
00:09:16,180 --> 00:09:21,680
 Ok, quindi questi messaggi PIM
 hanno tutti un tempo di vita.

120
00:09:21,680 --> 00:09:26,020
 Esatto, abbiamo visto come il join PIM star
 comma g Ã¨ andato allo stesso multicast

121
00:09:26,020 --> 00:09:30,200
 indirizzo come il ciao, 2240013.

122
00:09:30,200 --> 00:09:33,360
 Ora non l'ho realmente indicato nella traccia
 dello sniffer, ma proprio come il file

123
00:09:33,360 --> 00:09:44,720
 Ciao PIM, ha un tempo da vivere, PIM
 si unisce e diciamo il suo indirizzo

124
00:09:44,720 --> 00:09:55,220
 Ã¨ 55555. Quando l'unione PIM avviene proprio
 qui, nell'intestazione IP effettiva,

125
00:09:55,220 --> 00:10:01,160
 la fonte verrÃ  da quel ragazzo.

126
00:10:01,160 --> 00:10:06,060
 E la destinazione sarÃ  cosÃ¬.

127
00:10:06,060 --> 00:10:09,120
 Beh, in realtÃ  sarÃ  il router.

128
00:10:09,120 --> 00:10:11,820
 Questo ragazzo proprio qui, 4.5.4.4.

129
00:10:11,820 --> 00:10:18,040
 Diciamo solo questo, diciamo solo che
 Ã¨ il router 4 per renderlo semplice.

130
00:10:18,040 --> 00:10:24,100
 Quindi non c'Ã¨ necessariamente modo per il
 router 4 di sapere che questo si unisce

131
00:10:24,100 --> 00:10:28,800
 in realtÃ  ha avuto origine all'RP
 perchÃ© Ã¨ un salto dopo l'altro.

132
00:10:28,800 --> 00:10:43,360
 Quando l'RP lo ha inviato per la prima volta, l'RP
 lo ha inviato al router Z perchÃ© Ã¨ una virgola

133
00:10:43,360 --> 00:10:48,720
 g join conteneva le stesse informazioni.

134
00:10:48,720 --> 00:10:51,700
 La fonte era 4.5.4.5.

135
00:10:51,700 --> 00:10:56,500
 Il gruppo era 239.999.

136
00:10:56,500 --> 00:11:04,380
 E il pacchetto qui aveva un'origine
 IP dell'RP e una destinazione

137
00:11:04,380 --> 00:11:12,800
 router 4. Mettiamolo qui.

138
00:11:12,800 --> 00:11:18,440
 In realtÃ  no, la destinazione era
 il router Z perchÃ© Ã¨ hop by hop.

139
00:11:18,440 --> 00:11:22,540
 Ã solo un salto.

140
00:11:22,540 --> 00:11:27,040
 L'origine IP Ã¨ RP.

141
00:11:27,040 --> 00:11:32,480
 La destinazione Ã¨ uguale al router Z.

142
00:11:32,480 --> 00:11:36,820
 Quindi ha inviato questa virgola g join
 perchÃ© l'RP ha detto, okay, so chi Ã¨

143
00:11:36,820 --> 00:11:44,580
 la fonte Ã¨. Il mio prossimo
 vicino Ã¨ il router Z.

144
00:11:44,580 --> 00:11:49,440
 Quindi invierÃ² un PIM virgola g
 join a quel vicino dicendo: ehi

145
00:11:49,440 --> 00:11:52,140
 vicino, puoi aprirmi questa strada?

146
00:11:52,140 --> 00:11:55,660
 Quindi, quando il router Z lo
 ottiene, fa la stessa cosa.

147
00:11:55,660 --> 00:11:59,660
 Dice che il mio percorso sicuro
 verso la fonte Ã¨ il router 4.

148
00:11:59,660 --> 00:12:04,360
 Quindi creerÃ² un PIM s comma g
 join e lo invierÃ² al router 4.

149
00:12:04,360 --> 00:12:07,520
 Quindi questo si apre man mano che
 si procede lungo il percorso qui.

150
00:12:07,520 --> 00:12:11,120
 Questa interfaccia viene aperta nell'elenco
 delle interfacce in uscita.

151
00:12:11,120 --> 00:12:14,460
 Questa interfaccia viene aperta nell'elenco
 delle interfacce in uscita.

152
00:12:14,460 --> 00:12:19,600
 Ma quando il router 4 capisce questo, non ha
 idea del motivo per cui lo sta ricevendo

153
00:12:19,600 --> 00:12:23,600
 Ã¨ perchÃ© il RP ha avviato il processo.

154
00:12:23,600 --> 00:12:27,120
 Tutto quello che sa Ã¨ che ha ottenuto
 una s virgola g join per il router Z.

155
00:12:27,120 --> 00:12:32,080
 Non ha idea del motivo per cui
 il router Z glielo ha inviato.

156
00:12:32,080 --> 00:12:36,360
 Solo questo router Z l'ha capito,
 quel router Z lo ha avviato.

157
00:12:36,360 --> 00:12:41,400
 Quindi dice, beh, il router Z mi ha inviato
 questa virgola g join, ma io sono nel

158
00:12:41,400 --> 00:12:43,120
 processo di registrazione.

159
00:12:43,120 --> 00:12:44,780
 I due sono totalmente diversi.

160
00:12:44,780 --> 00:12:48,700
 Solo perchÃ© un ragazzo mi ha inviato un'iscrizione non
 significa che dovrei interrompere la registrazione

161
00:12:48,700 --> 00:12:51,300
 processo con un altro ragazzo.

162
00:12:51,300 --> 00:12:54,380
 ContinuerÃ² comunque a registrarmi
 perchÃ© non ho piÃ¹ notizie da

163
00:12:54,380 --> 00:13:05,700
 RP ancora. Tutto quello che ho sentito Ã¨ il
 router Z, di cui l'RP otterrebbe due copie

164
00:13:05,700 --> 00:13:06,900
 lo stesso pacchetto.

165
00:13:06,900 --> 00:13:09,880
 Quando il pacchetto multicast inizia a fluire
 verso il basso, scorrerÃ  in modo nativo

166
00:13:09,880 --> 00:13:15,240
 da 4 a Z a RP perchÃ© ormai questa
 strada Ã¨ stata aperta.

167
00:13:15,240 --> 00:13:19,240
 E allo stesso tempo, quando il router 4 ha ricevuto
 quel pacchetto multicast, ha creato

168
00:13:19,240 --> 00:13:25,240
 una copia di esso e lo ha incapsulato in unicast
 e lo ha trasmesso direttamente in unicast

169
00:13:25,240 --> 00:13:31,700
 al RP. Quindi ora l'RP dice,
 eh, okay, ottime notizie.

170
00:13:31,700 --> 00:13:37,400
 Ho appena ricevuto il vero pacchetto multicast
 nella sua forma nativa pura sul mio

171
00:13:37,400 --> 00:13:38,840
 albero del cammino piÃ¹ breve.

172
00:13:38,840 --> 00:13:42,160
 Ora so che la mia strada piÃ¹ breve
 verso la fonte Ã¨ aperta.

173
00:13:42,160 --> 00:13:44,340
 Sta scorrendo. Sta funzionando.

174
00:13:44,340 --> 00:13:47,240
 Dice: non ho piÃ¹ bisogno di
 questi messaggi di registro.

175
00:13:47,240 --> 00:13:50,380
 Questo mi fa lavorare piÃ¹ del necessario.

176
00:13:50,380 --> 00:14:00,520
 Quindi l'RP invierÃ  effettivamente quello che viene
 chiamato un messaggio di arresto del registro PIM

177
00:14:00,520 --> 00:14:05,060
 al router 4. Questo Ã¨ ciÃ² che
 il router 4 sta cercando.

178
00:14:05,060 --> 00:14:09,820
 CiÃ² gli farÃ  interrompere effettivamente
 il processo di registrazione.

179
00:14:09,820 --> 00:14:14,320
 Quindi so che in questo diagramma
 non era del tutto chiaro.

180
00:14:14,320 --> 00:14:22,400
 Potresti aver detto, okay, bene,
 quando l'app fermerÃ  la cassa,

181
00:14:22,400 --> 00:14:23,860
 Voglio mostrarti di no.

182
00:14:23,860 --> 00:14:28,920
 Questo non Ã¨. La registrazione continuerÃ 
 finchÃ© il RP non dirÃ  esplicitamente:

183
00:14:28,920 --> 00:14:32,900
 per favore fermati. Non voglio
 piÃ¹ vedere questi registri.

184
00:14:32,900 --> 00:14:40,100
 Quindi utilizza un messaggio di
 stop del registro per passare.

185
00:14:40,100 --> 00:14:44,780
 In realtÃ , non lo usa per passare al
 suo albero del percorso piÃ¹ breve.

186
00:14:44,780 --> 00:14:50,500
 Lo fa dopo che il suo albero del percorso
 piÃ¹ breve Ã¨ giÃ  stato aperto.

187
00:14:50,500 --> 00:15:05,720
 Quindi in realtÃ  sono disposto
 a cambiare la situazione.

188
00:15:05,720 --> 00:15:10,380
 LÃ¬, l'RP utilizza i messaggi di stop del registro
 dopo il suo albero del percorso piÃ¹ breve

189
00:15:10,380 --> 00:15:17,480
 Ã¨ confermato e aperto.

190
00:15:17,480 --> 00:15:20,320
 Questo Ã¨ il processo di
 registrazione del PIM.

191
00:15:20,320 --> 00:15:26,420
 Quindi andiamo avanti e diamo un'occhiata
 a questo e vediamo come funziona.

192
00:15:26,420 --> 00:15:32,340
 Quindi penso che in questo momento il nostro
 albero condiviso sia attualmente aperto.

193
00:15:32,340 --> 00:15:35,280
 Confermiamo e basta, andiamo sul router
 3 su RP e assicuriamoci che sia ancora

194
00:15:35,280 --> 00:15:46,720
 ha una stella, voce.

195
00:15:46,720 --> 00:15:48,680
 Oh, okay, non lo fa.

196
00:15:48,680 --> 00:15:53,640
 Torniamo alla nostra fonte,
 il nostro ricevitore qui.

197
00:15:53,640 --> 00:16:11,540
 Ok, ecco perchÃ©, perchÃ© non
 si Ã¨ unito al gruppo.

198
00:16:11,540 --> 00:16:14,500
 Ok, quindi ora dovremmo averlo.

199
00:16:14,500 --> 00:16:23,440
 Ok, quindi ecco la nostra stella, voce.

200
00:16:23,440 --> 00:16:27,680
 E inoltre, per quanto riguarda questi
 timer, questo timer qui Ã¨ come

201
00:16:27,680 --> 00:16:28,900
 tutta la vita di questo.

202
00:16:28,900 --> 00:16:30,620
 Questo continuerÃ  il conto alla rovescia.

203
00:16:30,620 --> 00:16:35,240
 E se mai il conto alla rovescia arrivasse
 a zero, significa che lo rimuoverÃ²

204
00:16:35,240 --> 00:16:38,580
 dall'elenco delle interfacce in uscita.

205
00:16:38,580 --> 00:16:43,640
 Ma sappiamo che finchÃ© quel ricevitore
 Ã¨ ancora attivo, purchÃ©

206
00:16:43,640 --> 00:16:48,120
 ci sono ancora domande in uscita e rapporti
 che ritornano, router 2 ciascuno

207
00:16:48,120 --> 00:16:54,420
 60 secondi, invieremo un'altra stella, unisciti
 qui per rinfrescare quello stato.

208
00:16:54,420 --> 00:16:59,720
 E anche il router 8 si siederÃ  quando
 lo riceverÃ , invieremo la sua stella,

209
00:16:59,720 --> 00:17:02,780
 join per aggiornare quello stato.

210
00:17:02,780 --> 00:17:12,280
 Quindi, per esempio, adesso
 siamo scesi a 233.

211
00:17:12,280 --> 00:17:14,080
 Ed Ã¨ tornato indietro.

212
00:17:14,080 --> 00:17:19,580
 Vedi, quindi abbiamo iniziato
 a tre minuti e 23 secondi.

213
00:17:19,580 --> 00:17:24,520
 E siamo scesi a circa un minuto.

214
00:17:24,520 --> 00:17:27,980
 E poi non l'abbiamo visto, ma sullo
 sfondo ha ricevuto una stella,

215
00:17:27,980 --> 00:17:31,500
 quanto ha aderito ad un aggiornamento,
 e tutto Ã¨ tornato a questo.

216
00:17:31,500 --> 00:17:38,740
 Questo qui, questo timer, Ã¨ il tempo trascorso
 in totale da questa interfaccia

217
00:17:38,740 --> 00:17:40,220
 l'elenco delle interfacce in uscita.

218
00:17:40,220 --> 00:17:44,100
 Quindi Ã¨ passato un minuto e quattro secondi da quando
 abbiamo ricevuto per la prima volta il nostro

219
00:17:44,100 --> 00:17:51,160
 prima stella, join che ha causato la creazione
 originaria di questa voce m-route.

220
00:17:51,160 --> 00:17:53,940
 Quindi questa volta continueremo
 ad aumentare.
