.dsy:it. (http://www.dsy.it/forum/)
- Reti di calcolatori II (http://www.dsy.it/forum/forumdisplay.php?forumid=291)
-- dubbi pre/pro esame (http://www.dsy.it/forum/showthread.php?threadid=31472)

dubbi pre/pro esame

RFC 2362 fine pagina 5

If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1.

Allora, il router ha una entry generica (tutte le sorgenti, quel gruppo) e riceve una join/prune per un'entry + specifica (sorgente, gruppo). Quindi crea cmq la entry, ma specificando l'RPT-bit in modo da sapere che quella rotta non viene usata per forwardare (il bit indica che i pacchetti della sorgente NON vanno forwardati su quel branch, perche' stanno usando uno SP tree e non lo shared tree)

__________________
When once you have tasted flight, you will walk the earth, forever more, with your eyes turned skyward. For there you have been, and there you long to return.

“Dovere, tempo, destino, tutto tende a separarci e, di fatto, ci separa. Ma il sentimento non conosce frontiere e mi unisce a te come se avessi sempre la mia mano sulla tua"

infatti.. .è la stessa cosa che avevo capito pure io... rimane pero il dubbio sul xke settare ad 1 il bit... continuo ad essere convito che dovrebbe essere 0, per dire al router di livello superiore: " se arrivano dati da questa determinata sorgente (S), per questo determinato gruppo (G), non propagarli."

bah... adex provo a leggere pure il paragrafo 3... spero ci sia qualche informazione piu chiara...

cmq un altro dubbio: secondo te, come sono fatte le table entry del router?
cosi: [SORGENTE; GRUPPO; IIF; OIF; RPT; WC; SPT] ? (con OIF ed IIF che possono contenere piu di un valore...)

Originally posted by CaboM.BNA


cmq un altro dubbio: secondo te, come sono fatte le table entry del router?
cosi: [SORGENTE; GRUPPO; IIF; OIF; RPT; WC; SPT] ? (con OIF ed IIF che possono contenere piu di un valore...)

__________________
When once you have tasted flight, you will walk the earth, forever more, with your eyes turned skyward. For there you have been, and there you long to return.

“Dovere, tempo, destino, tutto tende a separarci e, di fatto, ci separa. Ma il sentimento non conosce frontiere e mi unisce a te come se avessi sempre la mia mano sulla tua"

Attenzione: le oif possono contenere più di un valore ma le iif ne contengono ne contengono uno solo perchè sono la porta correlata al reverse path forwarding...Sarebbe come dire che un nodo ha due padri..ciao

__________________
Good wombs hath borne bad sons

Originally posted by Ari_85
Attenzione: le oif possono contenere più di un valore ma le iif ne contengono ne contengono uno solo perchè sono la porta correlata al reverse path forwarding...Sarebbe come dire che un nodo ha due padri..ciao

__________________
When once you have tasted flight, you will walk the earth, forever more, with your eyes turned skyward. For there you have been, and there you long to return.

“Dovere, tempo, destino, tutto tende a separarci e, di fatto, ci separa. Ma il sentimento non conosce frontiere e mi unisce a te come se avessi sempre la mia mano sulla tua"

sisi.. avete ragione... ero sovrappensiero e avevo scritto pure le IIF... mea culpa...

altro dubbio, stavolta a proposito di SRM...
Trattasi dell'ultimo paragrafo ("4.1 Chains") del documento sul Reliable Multicast...
ecco il link per vedere l'immagine
non riesco a capire PERCHE "se il nodo Rk se mandasse una request in unicast alla sorgente Lj, riceverebbe la repair non prima di t+2j+3k".

Io ho capito che:
1- Rk rileva che pacchetto non è arrivato al tempo [t]
2- Rk setta il request timer a [(j-1)+1+(k-1)] = [j+k-1]
3- La request arriva Lj dopo [k+j-1]
4- Lj setta il repair timer a [k+j-1]
5- La repair per arrivare a Rk ci impiega [k+j-1]
TEMPO TOTALE = t+(j+k-1)+(j+k-1)+(j+k-1)+(k+j-1)= t+4k+4j-4

Originally posted by CaboM.BNA
altro dubbio, stavolta a proposito di SRM...
l'immagine
non riesco a capire PERCHE "se il nodo Rk se mandasse una request in unicast alla sorgente Lj, riceverebbe la repair non prima di t+2j+3k".

__________________
When once you have tasted flight, you will walk the earth, forever more, with your eyes turned skyward. For there you have been, and there you long to return.

“Dovere, tempo, destino, tutto tende a separarci e, di fatto, ci separa. Ma il sentimento non conosce frontiere e mi unisce a te come se avessi sempre la mia mano sulla tua"

E' molto + semplice di quello che hai scritto tu. Con unicast NON si settano timer.
Il nodo RK rileva il loss a t+k . Unicasta SUBITO la request che arriva al nodo sorgente al tempo t+k+k+j (k+j e' la distanza tra RK e il nodo sorgente), cioe' a t+2k+j.
Il nodo sorgente risponde subito con una repair ci mette anch'essa k+j per arrivare a RK, quindi il tempo totale e' t+2k+j+k+j che facendo le somme diventa t+2j+3k
Sono stata comprensibile?

Viry, sei un tesoro! grazie mille..
Io davo per scontato che i timer si usassero cmq, ma che fosse solo la sorgente a poter inviare le repair...
(quasi) tutto chiaro adesso...

ho ancora un paio di perplessità però:

Il nodo RK rileva il loss a t+k

k+j e' la distanza tra RK e il nodo sorgente

tyzer... stavo postando la sessa cosa... in contemporanea...
cmq concordo con te...

E' tutta la mattina che mi ci sto incazzando dietro a sto articolo su SRM...vabbè se qualcuno sa qualcosa entro stasera se no qualcosa scriveremo

Originally posted by tyzer
Scusa, mi sembra ci sia un errore, perchè la distanza tra Rk ed il nodo Lj non è k+j, ma è (k-1)+j perchè da Rk ad R1 ci sono k-1 hop e poi da R1 a Lj ci sono j hop.

Quindi il nodo Rk rileva l'errore al tempo t+(k-1) e non al tempo t+k.

Facendo i conti così a me esce che Rk riceve il repair dopo:

(t+k-1) + 2*(j+k-1) = t+k-1 + 2j+2k-2 = t+2j+3k-3

Nell'articolo non li fa i conti...voi cosa ne dite?

__________________
When once you have tasted flight, you will walk the earth, forever more, with your eyes turned skyward. For there you have been, and there you long to return.

“Dovere, tempo, destino, tutto tende a separarci e, di fatto, ci separa. Ma il sentimento non conosce frontiere e mi unisce a te come se avessi sempre la mia mano sulla tua"

gradualmente ci sto arrivando...
OK... Rk rileva la loss a t+k... e fin qui va bene...
la propagazione della request e la propagazione della repair richiedono pero 2K+2J-2...