 | |
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 |
[Reti - Rossi] Secondo Compitino
Clicca QUI per vedere il messaggio nel forum |
| casper |
Apro la discussione anche se c'è ancora tempo (a proposito..ma la data del secondo conciderà con il primo appello?)
Ho un problema che non riesco a risolvere.
Si consideri un burst di 20 Mbyte/sec che ha durata di 50 msec.. Come
viene profilato questo burst da un token bucket di 500 Kbyte e flusso di
uscita a 2 Mbyte/sec che alimenta un leaky bucket da 10 Mbyte/sec ?
Il problema è lo stesso che viene usato per spiegare sul libro, a pagina 403-405 come funziona il sistema di un leaky bucket in coda ad un token buket.
Non riesco a capire come matematicamente possano saltare fuori quei 62 msec in cui si invia a 10MB/sec, che nemmeno il libro, spiega.
Grazie
:ciao: |
| spider |
ci provo: traff. in ingresso 20MBps per 50ms
quindi 20*8 Mbps *50/1000 sec = 8Mb
durata burst (vedi slide)-> S=Ct/(rl-rt)
Ct=500KByte=4Mbit rt=2MByte/s=16Mbps rl=10MByte/s=80Mbps
quindi
S = 4/(80-16)=0.0625sec = 62.5ms
abbiamo allora che del traffico in ingresso (8Mb)
5Mb (S*rl=0.0625sec*80Mbps=5Mb)li trasmetto a 62.5ms ed i 3Mb(8-5) restanti li trasmetto a 3Mb/rt=3/16=0.1875s=187.5ms circa 190ms |
| casper |
Grazie mille... :lode:
non appena mi passano i 40 di febbre cercherò di capire dove stato toppando !
:ciao: |
| spider |
domanda trovata in un tema d'esame :
quando viene applicato l'algoritmo di instradamento in una sottorete a circuito virtuale ? |
| dirkpitt |
Originally posted by spider
domanda trovata in un tema d'esame :
quando viene applicato l'algoritmo di instradamento in una sottorete a circuito virtuale ?
Azzardo:
al momento in cui creo la connessione?? |
| spider |
| ...dimenticavo, nelle slide a pag.4 |
| drakend |
| Il secondo compitino coincide con la data prevista per l'appello di gennaio vero? |
| dirkpitt |
Originally posted by drakend
Il secondo compitino coincide con la data prevista per l'appello di gennaio vero?
Il secondo compitino dovrebbe essere il 27 gennaio (ora e aula sono ancora sconosciute)
NOTA: alcuni voti del primo compitino erano sbagliati, guardate sul sito! |
| maynard80 |
Originally posted by dirkpitt
Il secondo compitino dovrebbe essere il 27 gennaio (ora e aula sono ancora sconosciute)
NOTA: alcuni voti del primo compitino erano sbagliati, guardate sul sito!
???? come sbagliati??? |
| SIMBIOS |
| si effettivamente il mio voto era errato.Meglio così va..... |
| polyethylene |
Il secondo compitino sarà il 27 gennaio, l'appello invece sarà il 28.
Fonte: l'avviso di oggi nel sito dsi.unimi.it. |
| casper |
Originally posted by SIMBIOS
si effettivamente il mio voto era errato.Meglio così va.....
Scusa ma come facevi a sapere che il tuo voto non era corretto se la visione dell'eleborato era (è) possibile solo dopo il secondo compito ? |
| SIMBIOS |
| perchè l'avevo fatto tutto giusto ed avevo preso 27 |
| spider |
dubbio:
se una rete di classe B ha subnet mask 255.255.248.0, qual è il massimo numero di host che possono esseri connessi in una subnet ?
11111111 | 11111111 | 11111000 | 00000000 |
8+3 =11 zeri quindi 2^11 =2048 ??? O c'è qualche altro metodo che mi sfugge ? |
| casper |
Originally posted by spider
dubbio:
se una rete di classe B ha subnet mask 255.255.248.0, qual è il massimo numero di host che possono esseri connessi in una subnet ?
11111111 | 11111111 | 11111000 | 00000000 |
8+3 =11 zeri quindi 2^11 =2048 ??? O c'è qualche altro metodo che mi sfugge ?
anche io l'ho sempre calcolato in quel modo..anche se effettivamente il dubbio che esista un metodo un po' meno "sporco" è venuto anche a me... |
| puntozip |
| Puoi non passare per la notazione binaria: l'ultima posizione è 0 quindi hai 256 host disponibili (da 0 a 255), nella penultima posizione hai 256-248=8 combinazioni per gli host quindi 256 * 8 = 2048. (in realtà sarebbero 2046 perchè non si possono usare gli indirizzi con tutti 1 e quella con tutti 0) Non so se è più comodo ma puoi usarlo come verifica. |
| drakend |
| Scusate ma del programma che c'è da studiare? Il 4, il 5, il 6 e il 2 del Kurose, giusto? |
| casper |
faccio un copy / paste dal sito della Pagani, indicando quello che dovrebbe essere argomento del secondo compito (io per il primo avevo studiato fino al 5.2)
5.3.1 General principles of congestion control
5.3.2 Congestion prevention policies
5.3.3 Congestion control in virtual circuit subnets
5.4.1 Quality-of-Service: requirements
5.4.2 Techniques for achieving good quality of service
5.5 Internetworking
5.6.1 Network layer in the Internet: the IP protocol
5.6.2 IP addresses
5.6.3 Internet control protocols
5.6.4 Interior gateway routing protocol: OSPF
5.6.5 Exterior gateway routing protocol: BGP
TANENBAUM: CAPITOLO 6
6.1 Transport Service [escluso 6.1.4]
6.2 Elements of transport protocols
6.4.1 Introduction to UDP
6.5 The Internet transport protocols: TCP [esclusi 6.5.11, 6.5.12]
6.6 Performance issues [escluso 6.6.5]
KUROSE: CAPITOLO 2
2.3 File transfer (FTP)
2.4 Electronic mail in the Internet
2.5 DNS
2.6 Socket programming with TCP
2.7 Socket programming with UDP
ATTENZIONE: Gli argomenti trattati nelle sezioni 2.4 e 2.5 del testo di Kurose possono essere studiati anche sul testo di Tanenbaum: sezione 7.1 (Domain Name System) e sezione 7.2 (Electronic Mail). In sostituzione della sezione 2.3 del testo di Kurose, e' disponibile un tutorial su FTP (in postscript). Per la programmazione con le socket si faccia riferimento alla documentazione disponibile nel Materiale Didattico. |
| Ariok |
RAgazzi confermate la parte da studiare?? c'e' altro ? qualche novita'?
Grande casper grazie! |
| drakend |
| A me sembra che ci sia tutto. |
| ale82info |
ATTENZIONE: Gli argomenti trattati nelle sezioni 2.4 e 2.5 del testo di Kurose possono essere studiati anche sul testo di Tanenbaum: sezione 7.1 (Domain Name System) e sezione 7.2 (Electronic Mail). In sostituzione della sezione 2.3 del testo di Kurose, e' disponibile un tutorial su FTP (in postscript). Per la programmazione con le socket si faccia riferimento alla documentazione disponibile nel Materiale Didattico.
ma di quale file si parla ??? |
| Bloody |
Originally posted by ale82info
ma di quale file si parla ???
di quello linkato alla scritta "tutorial su ftp" e nelle socket la lezione corrispondente nella pagina del materiale didattico |
| SIMBIOS |
| oh raga studiando mi sono imbattuto a pagina 460.MA quanto è razzista sto' libro???Leggete il punto 4 dove parla dei vincoli applicati al routing...è vergognoso sto libro. |
| spider |
domanda presa da tema d'esame :
quali sono le variabili considerate da TCP per svolgere il controllo di flusso ? |
| Skilotto83 |
Originally posted by SIMBIOS
oh raga studiando mi sono imbattuto a pagina 460.MA quanto è razzista sto' libro???Leggete il punto 4 dove parla dei vincoli applicati al routing...è vergognoso sto libro.
ma oltre quella...
a pagina 428 quando parla dei frammenti..."come sanno tutti i genitori...etc etc" e pag 418 secondo paragrafetto..."scrivere qui il nome della rete preferita"...
ma il sig.Tanenbaum si fuma li :cannabis: ? |
| dirkpitt |
Originally posted by Skilotto83
ma oltre quella...
a pagina 428 quando parla dei frammenti..."come sanno tutti i genitori...etc etc" e pag 418 secondo paragrafetto..."scrivere qui il nome della rete preferita"...
ma il sig.Tanenbaum si fuma li :cannabis: ?
Qualcosa di sicuro prende.... :D |
| spider |
...altra domanda ( ma c'è ancora qualcuno interessato ?)
In che cosa consiste il problema del crash receiver x una connessione di livello trasporto nel caso in cui il receiver adotti la tecnica di trasmettere l'ack prima della delivery delle TPDU all'entità di livello superiore ? |
| drakend |
| Il token bucket utilizza i token, che lo distinguono dal leaky bucket dal momento che permettono alla sorgente di trasmettere ad una velocità superiore a quella media per un tempo proporzionale al numero di token che ha accumulato. Il numero di token di solito riguarda il numero di pacchetti o di byte presenti contemporaneamente all'interno del bucket: il libro dice che comunque il numero di token non può essere superiore alla capacità del bucket stesso. Questo significa che un token bucket con capacità 10 MB trasmetterà 10 MB a, per esempio, 10 MB/sec invece di 1 MB/sec solo se ha accumulato 10 token da 1 MB e quindi nel caso che la sorgente non trasmettà dati per 10 unità di tempo? |
| puntozip |
Originally posted by spider
...altra domanda ( ma c'è ancora qualcuno interessato ?)
In che cosa consiste il problema del crash receiver x una connessione di livello trasporto nel caso in cui il receiver adotti la tecnica di trasmettere l'ack prima della delivery delle TPDU all'entità di livello superiore ?
La tdpu può essere persa se il crash avviene prima della consegna al livello superiore: il ricevente ha inviato la conferma ma non ha fatto in tempo a consegnare la tdpu, mentre il mittente ha ricevuto la conferma e quindi non la ritrasmette.
ciao |
| puntozip |
Originally posted by spider
...altra domanda ( ma c'è ancora qualcuno interessato ?)
In che cosa consiste il problema del crash receiver x una connessione di livello trasporto nel caso in cui il receiver adotti la tecnica di trasmettere l'ack prima della delivery delle TPDU all'entità di livello superiore ?
La tdpu può essere persa se il crash avviene prima della consegna al livello superiore: il ricevente ha inviato la conferma ma non ha fatto in tempo a consegnare la tdpu, mentre il mittente ha ricevuto la conferma e quindi non la ritrasmette.
ciao |
| spider |
| GRAZIE puntozip !!! |
| spider |
DRAKEND infatti ad es. l'esercizio di un tema d'esame
Assumere un regolatore "token bucket" con token da 100 byte, capacità di 500 byte e due token al secondo. Quali sono la velocità media, la velocità di picco e le dimensioni massime di un burst di questo regolatore? Possono essere trasmessi pacchetti da 800 byte?
La velocita' media sara' di 200 B/sec. perche' arrivano due token al secondo. La velocita' di picco non dipende dal regolatore. Le dimensioni massime di un burst sono 500 B. Non si puo' trasmettere un pacchetto da 800 B perche' non ci sono mai abbastanza token disponibili. |
| khelidan |
Originally posted by Skilotto83
ma oltre quella...
a pagina 428 quando parla dei frammenti..."come sanno tutti i genitori...etc etc" e pag 418 secondo paragrafetto..."scrivere qui il nome della rete preferita"...
ma il sig.Tanenbaum si fuma li :cannabis: ?
Scusa,ma hai visto dove e stato scritto il libro???:D
Vrije Universiteit
Amsterdam,the Netherlands
:cannabis: :cannabis: :cannabis: |
| ale82info |
Originally posted by khelidan
Scusa,ma hai visto dove e stato scritto il libro???:D
Vrije Universiteit
Amsterdam,the Nethelands
:cannabis: :cannabis: :cannabis:
e noi ci stiamo studiando i viaggi mentali di un olandese...! |
| drakend |
Il libro quando parla del NAT dice:
Using the Source port field, we can solve our mapping problem. Whenever an outgoing packet enters the NAT box, the 10.x.y.z source address is replaced by the company's true IP address. In addition, the TCP Source port field is replaced by an index into the NAT box's 65,536-entry translation table. This table entry contains the original IP address and the original source port. Finally, both the IP and TCP header checksums are recomputed and inserted into the packet. It is necessary to replace the Source port because connections from machines 10.0.0.1 and
10.0.0.2 may both happen to use port 5000, for example, so the Source port alone is not enough to identify the sending process.
When a packet arrives at the NAT box from the ISP, the Source port in the TCP header is extracted and used as an index into the NAT box's mapping table. From the entry located, the internal IP address and original TCP Source port are extracted and inserted into the packet. Then both the IP and TCP checksums are recomputed and inserted into the packet. The packet is then passed to the company router for normal delivery using the 10.x.y.z address.
Il mio dubbio è: quando il pacchetto arriva al nat box dall'isp perché estrae il Source port dall'header tcp e non il destination port? Il source del pacchetto di andata dovrebbe essere il destination di quello di ritorno, no? |
| casper |
si hai perfettamente ragione...io l'ho interpretato con un errore del libro...ragionando:
il pacchetto arriva dal client interno al dispositivo NAT che sostituisce il source port (ex, porta 12345) con un indice che punta alla tabellina che crea l'associazione porta origine e IP origine.
Quindi abbiamo nel source port questo numerello che indicizza la tabella...
il pacchetto parte...la destinazione compone il pacchetto di risposta inserendo nella PORTA DESTINAZIONE quello che gli è arrivato in porta sorgente (il nostro famoso 12345) e spara il pacchetto....
quando quindi il pacchetto giunge al NAT dall'ISP, NAT deve estrapolare il SOURCE PORT e andare a vedere nella tabellina a che porta sorgente - IP sorgente corrisponde...
quindi anche secondo me è sbagliato... |
| drakend |
Ancora un dubbio:
Cosa intende il libro quando dice che:
Fifth, some applications insert IP addresses in the body of the text. The receiver then extracts these addresses and uses them.
Quello che non capisco è il senso di fare un'operazione del genere: quali indirizzi ip vengono inseriti nel "body of the text" (che è? il payload del pacchetto?) |
| Bloody |
Ricordo ora e luogo:
Il secondo compito in corso d'anno si terrà giovedi 27 gennaio alle 16:30.
aula G21 (via Golgi): da ABBOU MOHAMMED a GENTILE CARLA compresi;
aula G24 (via Golgi): da GHEZZI MASSIMO a ZIPPO ANTONIO compresi.
L'appello del 28 gennaio si terrà alle ore 16:30 nelle aule V1 e V4 di via Venezian. |
| spider |
HELP!!!
Un'applicazione trasferisce su una connessione TCP 100 caratteri con un rate di carattere ogni 20ms. Il RTT è 300ms. Confrontare il numero di byte trasmessi (comprensivi di ack e di header TCP) nei 2 casi : 1) viene adottata la politica di Nagle di gestione finestra di trasmissione 2) non viene adottata alcuna politica di gestione finestre
a) 1420 24100
b) 1800 22100
c) 1420 22100
d) 1800 24100 |
| sampey |
dubbio!!!
l'esercizio 9 fatto in classe,relativo all'università di bologna
con reti da 194.76.16. a 194.76.23. calcolare la maschera.
come si risolve? considera 8 reti perchè l'ultimo otteto non
indicato vale 00000000 quindi 8 reti?
e come ottiene quella mask?
grazie!!!! |
| casper |
Originally posted by sampey
dubbio!!!
l'esercizio 9 fatto in classe,relativo all'università di bologna
con reti da 194.76.16. a 194.76.23. calcolare la maschera.
come si risolve? considera 8 reti perchè l'ultimo otteto non
indicato vale 00000000 quindi 8 reti?
e come ottiene quella mask?
grazie!!!!
se guardi negli esercizi pubblicati sul suo sito, trovi la soluzione anche di questo...comunque, sono 8 reti perchè vai da 16 a 23...per 8 reti ti servono 3 bit -> 2^3...metti a zero quindi anche gli ultimi 3 bit del penultimo ottetto oltre che quelli dell'ultimo, mentre tutto il resto va a 1...questo è il modo rapido per risolvero....se guardi sulle sue soluzioni trovi un modo più elegante...
:ciao:
ps. nessuno ha risolto ancora questo ?
Un'applicazione trasferisce su una connessione TCP 100 caratteri con un rate di carattere ogni 20ms. Il RTT è 300ms. Confrontare il numero di byte trasmessi (comprensivi di ack e di header TCP) nei 2 casi : 1) viene adottata la politica di Nagle di gestione finestra di trasmissione 2) non viene adottata alcuna politica di gestione finestre
|
| puntozip |
Originally posted by spider
HELP!!!
Un'applicazione trasferisce su una connessione TCP 100 caratteri con un rate di carattere ogni 20ms. Il RTT è 300ms. Confrontare il numero di byte trasmessi (comprensivi di ack e di header TCP) nei 2 casi : 1) viene adottata la politica di Nagle di gestione finestra di trasmissione 2) non viene adottata alcuna politica di gestione finestre
a) 1420 24100
b) 1800 22100
c) 1420 22100
d) 1800 24100
Io ho ragionato così ma i conti non mi tornano...(dove sbaglio?)
Senza Nagle il trasmittente invia 1 byte alla volta a cui aggiunge l'overhead dell'intestazione: totale (40 + 1) byte per ogni carattere trasferito (da moltiplicare per i 100 caratteri totali), ogni carattere ricevuto deve essere confermato con un ack che ha dimensioni pari all'intestazione tcp. Infine sommo i due totali...
Con Nagle aspetto l'ack x inviare più byte tutti insieme, quindi invio il primo byte con l'overhead dell'intestazione come prima, poi aspetto l'ack che impiega 300ms ad arrivare in quel tempo il trasmittente mette nel buffer 300/20=15 caratteri da inviare tutti in una volta con una sola intestazione, al secondo ack ne invio altri 15 e così via, l'ultimo invio sarà composto da 9 byte + intestazione; per quanto riguarda gli ack questi adesso dovrebbero essere cumulativi quindi uno per ogni ricezione.
Con Nagle risparmio perchè "spalmo" l'intestazione su più byte, e invio un numero inferiore di conferme. |
| casper |
idem...ma i conti non tornano...mancano un sacco di byte ad arrivare ad una possibile soluzione...
:? |
| spider |
..ne aggiungo un altro preso dagli esercizi della prof.ssa (n.16 ):
un host TCPsta inviando finestre di 65535 Byte su un canale da 1Gbps che ha ritardo one-way di 10ms. Qual è il MAX throughput ottenibile? Qual è l'efficienza della linea?
soluzione:
si invia una finestra ogni 20msec percio' il throughput è di 50 finestre al secondo ovvero
65535 * 50 =3276750=3.3MBps=26214Mbps
L'efficienza della linea è 26214/1000=2.621%
domanda, ma da dove arriva il valore 50 finestre? E perchè ogni 20 ms ? |
| casper |
Originally posted by spider
..ne aggiungo un altro preso dagli esercizi della prof.ssa (n.16 ):
un host TCPsta inviando finestre di 65535 Byte su un canale da 1Gbps che ha ritardo one-way di 10ms. Qual è il MAX throughput ottenibile? Qual è l'efficienza della linea?
soluzione:
si invia una finestra ogni 20msec percio' il throughput è di 50 finestre al secondo ovvero
65535 * 50 =3276750=3.3MBps=26214Mbps
L'efficienza della linea è 26214/1000=2.621%
domanda, ma da dove arriva il valore 50 finestre? E perchè ogni 20 ms ?
se 10ms è il tempo di sola andata (one-way) se lo moltiplichi per due ottieni 20 (tempo per riceve l'ack)....e se fai un secondo diviso 20 ms...ottieni 50
:ciao: |
| drakend |
Originally posted by puntozip
Io ho ragionato così ma i conti non mi tornano...(dove sbaglio?)
Senza Nagle il trasmittente invia 1 byte alla volta a cui aggiunge l'overhead dell'intestazione: totale (40 + 1) byte per ogni carattere trasferito (da moltiplicare per i 100 caratteri totali), ogni carattere ricevuto deve essere confermato con un ack che ha dimensioni pari all'intestazione tcp. Infine sommo i due totali...
Con Nagle aspetto l'ack x inviare più byte tutti insieme, quindi invio il primo byte con l'overhead dell'intestazione come prima, poi aspetto l'ack che impiega 300ms ad arrivare in quel tempo il trasmittente mette nel buffer 300/20=15 caratteri da inviare tutti in una volta con una sola intestazione, al secondo ack ne invio altri 15 e così via, l'ultimo invio sarà composto da 9 byte + intestazione; per quanto riguarda gli ack questi adesso dovrebbero essere cumulativi quindi uno per ogni ricezione.
Con Nagle risparmio perchè "spalmo" l'intestazione su più byte, e invio un numero inferiore di conferme.
Senza Nagle mi viene 16.100 byte, e quindi è un valore sballato.
41*100+(40+40+41)*100=16.100
Dove il primo 40 è l'ack, il secondo il windows update ed il terzo il pacchetto di echo. Se adotto la tecnica di ritardare l'ack il valore mi viene ancora più basso e quindi nemmeno se ne parla.
Per quanto riguarda la variante con Nagle io ho fatto il ragionamento che hai fatto tu, ma ci ho aggiunto sempre i valori del windows update e dell'echo... dato che l'esercizio cita solo Nagle e non il caso delle Silly Window, e quindi è lecito presumere che il ricevente non adotta nessuna particolare tecnica sulla sua finestra e sui suoi windows update in particolare.
I conti mi escono sbagliati pure qua, comunque il ragionamento che ho fatto è questo:
il mittente spedisce:
il primo pacchetto di 41 byte (header + primo carattere)
6 pacchetti per un totale di 330 byte (40+15)*6
un ultimo pacchetto da 49 byte
Totale: 420 byte
il destinatario manda:
per il primo pacchetto arrivato manda un ack (40 byte), un windows update (40 byte) e un'echo (41 byte). Totale: 121 byte
per ogni ack fra il 2° ed il 7° manda:
un ack (40 byte), un windows update (40 byte) e un'echo (55 byte). Totale: 810 byte
all'ultimo ack manda:
un ack (40 byte), un windows update (40 byte) e un'echo (49 byte). Totale: 129 byte
Il totale mi veniva 1460... non consideriamo qualcosa lato ricevente, dato che lato sorgente mi sembra tutto corretto. |
| casper |
domanda particolarmente stupida...
dato che mi sembra tutto corretto...non è che sono sbagliati i dati del problema o i risultati ? chi ha postato può controllare o indicare la fonte da dove sono stati presi ?
inoltre...anche io all'inizio avevo pensato di inserire i byte per il carattere di echo...ma il testo del problema non dice che è un'applicazione tipo telnet o simili...dice solo che si vogliono inviare un certo numero di caratteri...
|
| Polo |
Ho un paio di domande da fare riguardo gli esercizi:
1)
Prendendo come esempio l'esercizio 9, su la maschera per fare CIDR.
Se se le reti fossero state 12 anzichè 8 la maschera avrebbe potuto eseere
11111111.11111111.11110010.00000000
cioè
255.255.244.0
o deve comunque essere
11111111.11111111.11110000.00000000
cioè come spostandosi di potenze di 2
255.255.240.0
?
2)
esercizio numero 17, nella formula per calcolare il massimo trouhgput:
(massimo numero sequenza x grandezza TPDU x 8 bit )
non capisco cosa sia 8 bit?
3)
L'ercizio sul distant vector è da fare?
4)
la parte sulle soket in java può essere chiesta nel compitino?
Grazie mille a chiunque mi dia una mano |
| spider |
ho fatto un copia e incolla dal tema d'esame del 20/02/2003
6) Un’applicazione trasferisce su una connessione TCP 100 caratteri con un rate di un carattere ogni
20 msec. Il round trip time è 300 msec. Confrontare il numero di byte trasmessi (comprensivi di ack
e di header TCP) nei due casi: 1) viene adottata la politica di Nagle di gestione finestra di
trasmissione. 2) non viene adottata alcuna politica di gestione finestre
a) 1.420, 2.4100
b) 1.800, 2.2100
c) 1.420, 2.2100
d) 1.800, 2.4100
...prendendo come esempio l'esercizio 9, su la maschera
256-reti assegnate quindi 256-12=244
255.255.244.0 11111111.11111111.11110010.00000000
...esercizio numero 17, nella formula..TPDU x 8 bit
perche' TPDU 128Byte quindi in bit 128X8
...ercizio sul distant vector
penso di no ,ma non sono sicuro
...la parte sulle soket in java può essere chies..
SI |
| puntozip |
Originally posted by spider
...prendendo come esempio l'esercizio 9, su la maschera
256-reti assegnate quindi 256-12=244
255.255.244.0 11111111.11111111.11110010.00000000
La maschera 255.255.244.0 non è valida, deve essere composta da tutti 1 consecutivi da sinistra:
11110100 ha un "buco"... |
| puntozip |
Originally posted by drakend
...
Il totale mi veniva 1460... non consideriamo qualcosa lato ricevente, dato che lato sorgente mi sembra tutto corretto.
La risposta giusta sembrerebbe la a) se non si considerano gli ack...
Solo trasmittente con nagle:
41+(55*6)+49=420
Solo trasmittente senza nagle:
41*100=4100
inizialmente mi sembrava fosse scritto 1420 come risultato e non 1) 420 e mi ha portato fuori strada...
PS grazie drakend per i tuoi interventi, mi aiutano sempre a riprendere il libro e ad approfondire gli argomenti...
Ciao |
| puntozip |
Ci sono! la notte ha portato consiglio...
Si contano anche gli ack ma il testo parla solo di intestazione tcp, quindi 20 byte e non 40 come stavamo considerando (dovuta a tcp e ip).
Contando la dimensione in questo modo la risposta a) è quella corretta.... |
| drakend |
Originally posted by puntozip
Ci sono! la notte ha portato consiglio...
Si contano anche gli ack ma il testo parla solo di intestazione tcp, quindi 20 byte e non 40 come stavamo considerando (dovuta a tcp e ip).
Contando la dimensione in questo modo la risposta a) è quella corretta....
Dunque gli ack vanno inclusi, lo dice esplicitamente il testo. Anche considerando solo l'header tcp i conti vengono:
il mittente spedisce:
il primo pacchetto di 21 byte (header + primo carattere)
6 pacchetti per un totale di 210 byte (20+15)*6
un ultimo pacchetto da 29 byte
Totale: 260 byte
il destinatario manda:
per il primo pacchetto arrivato manda un ack (20 byte), un windows update (20 byte) e un'echo (21 byte). Totale: 61 byte
per ogni ack fra il 2° ed il 7° manda:
un ack (20 byte), un windows update (20 byte) e un'echo (35 byte). Totale: 450 byte
all'ultimo ack manda:
un ack (20 byte), un windows update (20 byte) e un'echo (29 byte). Totale: 69 byte
Il totale dei byte trasmessi (adottando Nagle), includendo window update ed echo, viene 840 byte... figuriamoci togliendoci il window update e l'echo.
Quindi come fai a dire che la risposta giusta è la a? |
| puntozip |
La risposta (a) dice:
420 Byte con nagle e 4100 Byte senza nagle
L'echo non lo devi considerare perchè nel testo non si fa riferimento ad un'applicazione tipo telnet che deve visualizzare l'output remoto sul mittente e i window update viaggiano sugli ack, quindi rivedendo i tuoi calcoli abbiamo:
Senza Nagle:
100 pacchetti da 21 Byte => totale 2100
100 Ack da 20 Byte => 2000
2100 + 2000 = 4100 Byte OK
Con Nagle:
1 pacchetto da 21 Byte
6 pacchetti da 35 Byte => totale 210
1 pacchetto da 29 Byte
8 Ack da 20 Byte => 160
21 + 210 + 29 + 160 = 420 Byte |
| drakend |
Originally posted by puntozip
La risposta (a) dice:
420 Byte con nagle e 4100 Byte senza nagle
Scusa ma la risposta a) non dice mica:
a) 1.420, 2.4100 |
| casper |
Originally posted by drakend
Scusa ma la risposta a) non dice mica:
a) 1.420, 2.4100
non so se centra...ma credo che gli 1. e il 2. si riferiscano al numero della domanda....
se così fosse il problema è risolto... |
| spider |
...anche secondo me gli 1. e il 2. si riferiscano al numero della domanda.
Ma cmq perchè 6 pacc. da 35 B, 1 pacc. da 29 Byte e 8 Ack da 20 ? |
| SIMBIOS |
| la risposta corretta è sempre la A |
| spider |
| ...non c'è piu' nessuno??? |
| puntozip |
Con Nagle aspetto l'ack x inviare più byte tutti insieme, quindi invio il primo byte con l'overhead dell'intestazione, poi aspetto l'ack che impiega 300ms ad arrivare in quel tempo il trasmittente mette nel buffer 300/20=15 caratteri da inviare tutti in una volta con una sola intestazione, al secondo ack ne invio altri 15 e così via, l'ultimo invio sarà composto da 9 byte + intestazione; per quanto riguarda gli ack questi adesso dovrebbero essere cumulativi quindi uno per ogni ricezione.
Passo-Passo
Il primo invio è composto da 1 byte di dati e 20 di intestazione -> totale 21
rimangono 99 byte di dati da inviare
Il secondo invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 99 -15 = 84 byte di dati da inviare
Il terzo invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 84 -15 = 69 byte di dati da inviare
Il quarto invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 69 -15 = 54 byte di dati da inviare
Il quarto invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 54 -15 = 39 byte di dati da inviare
Il quinto invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 39 -15 = 24 byte di dati da inviare
Il sesto invio è composto da 15 byte di dati e 20 di intestazione -> totale 35
rimangono 24 -15 = 9 byte di dati da inviare
Il settimo invio è composto dagli ultimi 9 byte di dati e 20 di intestazione -> totale 29
Quindi invio all'inizio 21 byte, all'ultimo invio 29 byte e nel mezzo invio 35 byte per 6 volte
Faccio in totale 8 invii per ognuno dei quali ricevo un ack di sola intestazione (20 byte)
Ciao |
| Ariok |
RAgaziz una domanda su un esercizio (il numero 5 del ps della pagani)
Un leaky bucket con capacita’ C_l=1.5 Mb e r_l=2 Mbps riceve traffico da una
sorgente che genera dati a 5 Mbps per 500 msec. Qual e’ il profilo del traffico in
uscita dal leaky bucket?
peche' un mb viene droppato??? il calcolo brutale sarebbe
2.5 Mb(inteso come 500x5) meno la capacita'(1,5Mb)? |
| spider |
peche' un mb viene droppato??? il calcolo brutale sarebbe
2.5 Mb(inteso come 500x5) meno la capacita'(1,5Mb)?
Giustissimo ! 1Mb viene scartato. |
| Ariok |
| ok ..domanda veramente idiota... perdonatemi!!! :P |
| puntozip |
Ho trovato alcuni trucchetti per il calcolo delle subnet.
Per calcolare il numero di bit necessari per creare la subnet mask corretta:
1) Aggiungere 1 al numero di subnet che si vogliono ottenere. Se 8, si calcola 9. Se 30, si calcola 31 e così via
2) Convertire questo numero decimale in binario
decimale binario
9 1001
31 11111
3) Determinare il numero di bit necessari per la subnet mask: Questo numero è il numero di cifre della
notazione binaria che abbiamo appena determinato.
Binario # di Bit
1001 4
11111 5
4) Aggiungere questo numero di 1 alla porzione network della subnet mask standard.
# of Bits Class A Binary Subnet Mask
4 1111 1111.1111 0000.0000 0000.0000 0000
5 1111 1111.1111 1000.0000 0000.0000 0000
Convertite in decimale, queste subnet masks sono:
# of Bits Decimal Subnet Mask
4 255.240.0.0
5 255.248.0.0 |
| puntozip |
C’è un modo semplice per determinare gli indirizzi validi per una data subnet mask. Per esempio 192 in binario è 1100 0000, il valore decimale dell’ultimo bit a destra che ha valore 1 è 64. quindi il primo indirizzo è 64 e i successivi sono multipli di 64 (128...)
Per esempio consideriamo l’indirizzo 131.107.0.0 e cerchiamo di creare 4 subnet:
1. aggiungo 1 al numero di subnet che voglio: 4 + 1 = 5.
2. Converto 5 in binario: 101.
3. 101 ha 3 bits, che sono il numero di bit che mi serve per la subnet mask, la quale diventa 255.255.224.0.
4. L’ultimo bit a 1 in 224 (in binario) vale 32 in decimale. Questo è il primo network number.
quindi per creare 4 subnet da 131.107.0.0, si usa la subnet mask 255.255.224.0, e le 4 network saranno:
131.107.32.0
131.107.64.0
131.107.96.0
131.107.128.0 |
| drakend |
Io ho questo problema qua:
Il risultato finale mi viene di 192 ms, invece che di 190 ms per l'output a 2 MB/sec. Come mai? |
| SIMBIOS |
| ma infatti il risultato è 192 ms per l'output a 2MB/sec.Non hai sbagliato nulla |
| sampey |
sarà anche giusto il risultato 192,ma perchè negli esercizi fatti in classe con la pagani e precisamente il numero 7 si usa un'altra
formula? mi spiego:
in classe si inziava con S=C/r_l - r_t mentre qui si utilizza
S= C/M_t - r_t perchè? ci sono delle ragioni particolari?
qui l'esercizio si prolunga parecchio,in classe no?
crisi prima del compito.....
grazie |
| sampey |
un altro dubbio aiuto!
da dove arrivano questi valori e perchè,mi riferisco all'esercizio:
Si consideri un burst di 20 Mbyte/sec che ha durata di 50 msec.. Come
viene profilato questo burst da un token bucket di 500 Kbyte e flusso di
uscita a 2 Mbyte/sec che alimenta un leaky bucket da 10 Mbyte/sec ?
e al risultato proposto nel forum:
ci provo: traff. in ingresso 20MBps per 50ms
(non dovrebbe essere 1 Mb di dati???)
quindi 20*8 Mbps *50/1000 sec = 8Mb
(questa formula dove la trovo????)
durata burst (vedi slide)-> S=Ct/(rl-rt)
Ct=500KByte=4Mbit rt=2MByte/s=16Mbps rl=10MByte/s=80Mbps
(da dove spuntano i 4Mbit e i 16Mbps e 80 Mbps???)
quindi
S = 4/(80-16)=0.0625sec = 62.5ms
(e questa?????)
abbiamo allora che del traffico in ingresso (8Mb)
5Mb (S*rl=0.0625sec*80Mbps=5Mb)li trasmetto a 62.5ms ed i
(e questa????)
3Mb(8-5) restanti li trasmetto a
(e questa????)e questa????)
3Mb/rt=3/16=0.1875s=187.5ms circa 190ms
ps: i commenti tra parentesi si riferiscono ai passaggi sopra
aiuto e confido in voi...... |
| spider |
...infatti ho notato la stessa cosa, secondo gli esercizi della Prof.ssa prima si verifica se
r_t < r_l < M_t e in questo caso lo è 2MB<10MB<25MB
poi si calcola S
che con T_B + L_B è S= C_t / (r_l - r_t)=0.0625s
tempo in cui vengono smaltiti r_l*S=10MB*0.0625s=0.625MB
I rimanenti 1MB(traff. in entr.)-0.625MB=0.375MB vengono smaltiti a r_t=2MB in 0.187s (0.375MB/r_t)
-----0.625MB in 62.5ms
riassumendo 1MB |
-----0.375MB in 187ms |
| spider |
...ovviamente mi riferivo alla prima domanda di sampey
"sarà anche giusto il risultato 192,ma perchè negli esercizi fatti in classe con la pagani e precisamente il numero 7 si usa un'altra.." |
| puntozip |
Originally posted by sampey
ci provo: traff. in ingresso 20MBps per 50ms
(non dovrebbe essere 1 Mb di dati???)
quindi 20*8 Mbps *50/1000 sec = 8Mb
(questa formula dove la trovo????)
Tranquillo, l'unica cosa che ti è sfuggita è la conversione tra bit e byte (rispettivamente b minuscola e B maiuscola):
esempio i 20 Mbyte/sec in 50 msec diventano
20(MByte/sec) * 8 (numero di bit per byte)= 160 Mb (MBit/sec)
50 Msec= 0,05 sec
160 Mb (MBit/sec) * 0,05 sec = 8 Mbit |
| Ariok |
VAdo un po' piu' sul materiale ......
Qualcuno sa come sara' impostato il compito ? domande a risposta aperta ..o a scelta multipla? |
| spider |
| ...spero e penso come il primo compitino domande a scelta multipla e a risposta libera |
| drakend |
Altro dubbio:
Il libro dice che la subnet dell'università di Oxford (che deve essere di 4096 host) non la posso far partire da 194.24.12.0 perché deve stare un un "4096 byte boundary"... cioè che vuol dire traditto in termini più comprensibili?
Perché la subnet la fa invece partire da 194.24.16.0? |
| Ariok |
| si risposta libera intendi esercizi...ok.. spero anche io sia cosi' .. mi viene il dubbio che visti i problemi che ci sono stati per le correzioni risultate errate ..la prof opti per qualcos'altro...speriamo di no |
| drakend |
Originally posted by sampey
sarà anche giusto il risultato 192,ma perchè negli esercizi fatti in classe con la pagani e precisamente il numero 7 si usa un'altra
formula? mi spiego:
in classe si inziava con S=C/r_l - r_t mentre qui si utilizza
S= C/M_t - r_t perchè? ci sono delle ragioni particolari?
qui l'esercizio si prolunga parecchio,in classe no?
crisi prima del compito.....
grazie
Io gli esercizi non li avevo ancora guardati: ho provato a fare da solo uno degli esempi sul libro. I numeri bene o male tornato direi, però il procedimento indicato dalla professoressa è decisamente più rapido ed infatti vedrò bene di fare quello nel compitino, anche perché non è che ci sia tutto questo tempo... |
| Ariok |
Una connessione TCP usa la politica di Clark lato receiver. L’applicazione legge 1 byte
ogni 10 msec., il segmento e’ di dimensione pari a 1024 byte, il buffer lato receiver e’ di 500
byte. Indicare ogni quanto tempo viene spedita al sender una TPDU di window update.
a) ogni 250 msec
b) ogni 500 msec
c) ogni 10 msec.
d) In un tempo che e’ funzione del tempo necessario al receiver per fare piggyback
dell’acknowledgment su una TPDU destinata alla sorgente
La risposta corretta e' sempre la a)
vi torna ? a me no....
ogni 10 msec... in 250 msec ....riceve 25 byte....e non siamo a meta' del buffer del ricevente ..e tanto meno lo abbiamo riempito tutto..!!
cosa sbaglio nel ragionare su questo quesito??? |
| polyethylene |
| Qualcuno mi spiega dov'è via Golgi (aula G21 e G24) ? :D:D |
| Skilotto83 |
via golgi è la strada che incontri se fai tutta via celoria...alla fine c'è via golgi...
kmq le aule sono nel settore G...pratikamente dove c'è il bar..
Nella sede centrale di via celoria...
|
| Ariok |
15.[T6.20] Se il rtt TCP e’ correntemente 30 msec e i seguenti ack arrivano dopo 26
msec, 32 msec e 24 msec dalle rispettive trasmissioni, qual e’ la nuova stima di
RTT usando a=0.9?
RTT_1 = 0.9 x 30 + 0.1 x 26 = 29.6
scusate Lo 0,1 e' dato da 1- 0,9 (cioe' alpha)???
.. intend ose avessi avuto alpha a 0.8 il valore per il calcolo sarebbe stato 0.2?!?!?!? |
| Bloody |
Lo 0,1 e' dato da 1- 0,9 (cioe' alpha)???
sì! Alfa è un valore dato dal testo del problema, praticamente l'importanza che l'amminstratore di sistema decide di assegnare al rtt vecchio invece che a quello appena misurato |
| drakend |
Guardate lo pseudoheader:
Perché il tcp segment length è lungo 15 byte e non 16? In fondo la lunghezza massima di un segmento TCP dovrebbe essere di 65515 byte no? |
| SIMBIOS |
| Se vai a vedere nella RFC è lungo 16. |
| Ariok |
dato ceh c'e 'blood in giro ne approfitto muamuaaum
[T6.19] Si supponga che la finestra di congestione di TCP e’ di 18 KB nel
momento in cui si verifica un timeout. Quando sara’ grande la finestra se le
successive 4 trasmissioni avvengono con successo? Si assuma che la max
dimensione di segmento sia 1 KB.
Riparto da Max TPDU=1 KB; alla seconda trasmissione invio 2 KB, alla terza 4 KB e
infine alla quarta invio 8 KB.
Mi manca un passaggio.... in tutto questo a cosa serve sapere che la finestra d icongestione e' 18kb??
18 /2 threshold giusto?? ma non riesco a capire.. :( |
| casper |
Originally posted by Ariok
dato ceh c'e 'blood in giro ne approfitto muamuaaum
[T6.19] Si supponga che la finestra di congestione di TCP e’ di 18 KB nel
momento in cui si verifica un timeout. Quando sara’ grande la finestra se le
successive 4 trasmissioni avvengono con successo? Si assuma che la max
dimensione di segmento sia 1 KB.
Riparto da Max TPDU=1 KB; alla seconda trasmissione invio 2 KB, alla terza 4 KB e
infine alla quarta invio 8 KB.
Mi manca un passaggio.... in tutto questo a cosa serve sapere che la finestra d icongestione e' 18kb??
18 /2 threshold giusto?? ma non riesco a capire.. :(
occhio...che dice 4 trasmissioni ok...quindi dopo la 4 trasmissione ricevi l'ACK che ti permette di settare la nuova finestra di congestione...dovresti raddoppiare il precedente 8 che diventa un 16, ma sei costretto a scegliere la minima tra questa a la soglia che è a 9...quindi segli quella della soglia a 9...
setti quindi la congestion a 9...e da li in poi salirai linearmente e non più esponenzialmente
:ciao: |
| Ariok |
Originally posted by casper
occhio...che dice 4 trasmissioni ok...quindi dopo la 4 trasmissione ricevi l'ACK che ti permette di settare la nuova finestra di congestione...dovresti raddoppiare il precedente 8 che diventa un 16, ma sei costretto a scegliere la minima tra questa a la soglia che è a 9...quindi segli quella della soglia a 9...
setti quindi la congestion a 9...e da li in poi salirai linearmente e non più esponenzialmente
:ciao:
Ok ok !! capito grazie mille!!
Mi sta venend oil panico da esame ..... non mi ero ancora posto ste domande :P effettivamente leggendo bene il paragrafo dove parla dell'avio lento potevo arrivarci .... ma sono un po' alle cozze!! grazie casper! |
| bono vox U2 |
| X superare l'esame di reti (devo ancora iniziare a studiare) cosa mi consigliate, è necessario studiare ank dal libro o le slide bastano e avanzano??? |
| drakend |
Originally posted by spider
con T_B + L_B è S= C_t / (r_l - r_t)
Quindi la durata del burst in caso di token+leaky è questa? Mentre nel caso generale è quella che ho usato io nel mio svolgimento dell'esercizio, mettendo cioè M_T al posto r_l? |
| bill76 |
Scusate ma ho trovato una domanda in vecchi temi d'esame:
Com'e possibile spedire un file binario nel corpo della mail?
Fatemi sapere! |
| drakend |
Originally posted by bill76
Scusate ma ho trovato una domanda in vecchi temi d'esame:
Com'e possibile spedire un file binario nel corpo della mail?
Fatemi sapere!
Codificandola in base 64, cioè raggruppando la stringa binaria in gruppi da 6 bit e rappresentarli come caratteri ascii stampabili. \r\n sono ignorati. |
| Bloody |
x bono: non bastano assolutamente le slide, stavolta devi farti il libro... basta che dai un'occhiata ai temi d'esame
x bill76: usando il MIME |
| SIMBIOS |
Originally posted by bono vox U2
X superare l'esame di reti (devo ancora iniziare a studiare) cosa mi consigliate, è necessario studiare ank dal libro o le slide bastano e avanzano???
E' assolutamente necessario studiare dal libro |
| polyethylene |
Originally posted by casper
occhio...che dice 4 trasmissioni ok...quindi dopo la 4 trasmissione ricevi l'ACK che ti permette di settare la nuova finestra di congestione...dovresti raddoppiare il precedente 8 che diventa un 16, ma sei costretto a scegliere la minima tra questa a la soglia che è a 9...quindi segli quella della soglia a 9...
setti quindi la congestion a 9...e da li in poi salirai linearmente e non più esponenzialmente
:ciao:
quindi dopo 4 ritrasmissioni ho la congestion windows di 16KB e il valore di Threshold a 9KB, e quindi devo scegliere il minimo valore, giusto ?
Quindi la soluzione del problema è 9KB ?
uhm..., forse non ho capito |
| polyethylene |
Originally posted by polyethylene
quindi dopo 4 ritrasmissioni ho la congestion windows di 16KB e il valore di Threshold a 9KB, e quindi devo scegliere il minimo valore, giusto ?
Quindi la soluzione del problema è 9KB ?
uhm..., forse non ho capito
forse ho capito:
in pratica al momento del time out la soglia diventa quanto la metà della congestion window: quindi la congestion window era di 18 KB, e la soglia diventa di 9 KB.
La congestion window riparte da 1KB, e cresce esponenzialmente fino a raggiungere la soglia (che è di 9KB), poi cresce linearmente.
Ma in questo caso la congestion window non supera la soglia (di 9 KB), perchè dopo 4 trasmissioni diventa di 8KB:
t1 = 1KB
t2 = 2KB
t3 = 4KB
t4 = 8KB
quindi la congestion window è di 8 KB
ho sbagliato qualcosa ? |
| Skilotto83 |
[T6.19] Si supponga che la finestra di congestione di TCP e? di 18 KB nel
momento in cui si verifica un timeout. Quando sara? grande la finestra se le
successive 4 trasmissioni avvengono con successo? Si assuma che la max
dimensione di segmento sia 1 KB.
Riparto da Max TPDU=1 KB; alla seconda trasmissione invio 2 KB, alla terza 4 KB e
infine alla quarta invio 8 KB.
il discroso è se lui vuole che si usi l'avvio lento o l'algoritmo di congestione...
secondo me la cosa è kosi'...con algoritmo di congestione:
la finestra di cong è a 18kB il timeout fa si' ke la soglia venga dimezzata...e il calcolo ricominci con il solito slow-start(avvio lento)
la soglia è ora a 9KB...
in 4 trasmissione ok arrivo a 8KB...quindi nn c'è alcon problema..perkè nn arrivo neanke a 9KB
se le trasmissioni fossero state 5 mi sarei fermato a 9K..se fossero state 6 a 10K etc..linearmente...
piu' ke altro l'esercizio sekondo me nn serve a far capire che poi cresce linearmente...
nn mi sembra che c'entri niente con il calcolo della corretta dimensione della finestra di congestione...che è appunto il fermarsi alla dimensione prima del timeout...no?? |
| polyethylene |
Originally posted by Skilotto83
nn mi sembra che c'entri niente con il calcolo della corretta dimensione della finestra di congestione...che è appunto il fermarsi alla dimensione prima del timeout...no?? [/B]
sì, infatti, hai detto le stesse cose che ho scritto io :) |
| Skilotto83 |
no..
tu hai scritto 18/2=8...e nn so perkè...
ma cmq pensavo che tu ti fossi fermato a 8 perkè il limite..in realta' il limite è 9..quindi il problema nn si pone..ti fermi a 8 perkè li' arvi kn 4 itrasmissioni...mentre casper sosteneva di fermarsi a 9 perkè 4 trasmissione kn successo sekondo lui significa che poi fai la 5a e ti fermi al limite max di soglia invece che a 16...ma nn penso sia kosi'...
kapito?? |
|
|
|
|
