 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
dubbi pre/pro esame
Clicca QUI per vedere il messaggio nel forum |
| CaboM.BNA |
RFC 2362 fine pagina 5
If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1.
qualcuno saprebbe spiegarmi il perche?
per dire al router di livello superiore che non si volgiono ricevere piu pacchetti (per quel gruppo, da quella determinata sorgente) dovrei mettere il RPT-bit a 0, no?
il RPT-bit non indica mica che i dati viaggiano su uno shared tree attraverso un RP, giusto? |
| Viry |
| 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) |
| CaboM.BNA |
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...) |
| Viry |
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...)
direi di si... |
| 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 |
| Viry |
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
si, avevo letto che l'entry puo' contenere piu' valori solo nel caso delle oif. (l'interfaccia di ingresso e' una sola, ovviamente, se no i controlli sulla provenienza di un pacchetto non avrebbero senso) |
| CaboM.BNA |
| sisi.. avete ragione... ero sovrappensiero e avevo scritto pure le IIF... mea culpa... |
| CaboM.BNA |
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 |
| Viry |
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".
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? |
| tyzer |
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?
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? |
| CaboM.BNA |
Viry, sei un tesoro! grazie mille.. :lode:
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
secondo me dovrebbe essere t+k-1
e
k+j e' la distanza tra RK e il nodo sorgente
questa invece sarebbe k+j-1 :
da Lj a L1 è j-1
da L1 a R1 è 1
da R1 a Rk è k-1
TOTALE j-1+1+k-1=j+k-1
è vero che per j>>1 e k>>1 sarebbe praticamente ininfluente però penso che la repair dovrebbe arrivare a t+3k+2j-3 |
| CaboM.BNA |
:lol:
tyzer... stavo postando la sessa cosa... in contemporanea...
cmq concordo con te... |
| tyzer |
| 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 ;) |
| Viry |
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?
Cosi' non prendi in considerazione il fatto che bisogna attraversare anche r1...
Il -1 si usa per calcolare il tempo in cui il request GENERATO dal nodo k1 arriva al nodo rk (infatti il request percorre un hop in meno, perche' non deve attraversare r1 che invece viene attraversato per raggiungere la sorgente)
|
| CaboM.BNA |
:pensa: 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... |
| tyzer |
Cosi' non prendi in considerazione il fatto che bisogna attraversare anche r1...
Il -1 si usa per calcolare il tempo in cui il request GENERATO dal nodo k1 arriva al nodo rk (infatti il request percorre un hop in meno, perche' non deve attraversare r1 che invece viene attraversato per raggiungere la sorgente)
Ma come distanza tu intendi il numero di stazioni attraversate? Io intendo il numero di link attraversati...
Non ho capito bene la tua spiegazione di prima...sull'articolo dice:
Let each link have distance 1
cioè intende che i link (cioè i fili che collegano una pallina all'altra ;) ) valgono 1, quindi le distanze le conta come numero di link attraversati...o no? |
| Viry |
Originally posted by tyzer
(cioè i fili che collegano una pallina all'altra ;) )
Visto che ti metti pure a sfottere, perche' non ci illumini tu dall'alto della tua sapienza? |
| tyzer |
Visto che ti metti pure a sfottere, perche' non ci illumini tu dall'alto della tua sapienza?
Non era per sfottere! E' che non sapevo come esprimere il concetto di link :(
Comunque ho detto giusto? |
| CaboM.BNA |
| yess... link=hop="pezzeto di filo tra 2 host/router".. |
| Viry |
Effettivamente, puo' sorgere il dubbio per quel -1 --- boh, secondo me l'importante e' cmq saper spiegare che la versione multicast su topologia a chain e' piu' performante della versione unicast, e basta (spero)
Alla fine, per k e j non minuscoli, il -1 conta poco... |
| CaboM.BNA |
| no, non che multicast è piu performante di unicast.. ma che "è piu conveniente se a rimandare il dato perso è un altro nodo (quello piu prossimo al punto di rottura e perciò pure l'ultimo ad aver ricevuto i dati corretti) piuttosto che richiedere la REPAIR direttamente alla sorgente".. |
|
|
|
|
