.dsy:it. (http://www.dsy.it/forum/)
- Reti di calcolatori (http://www.dsy.it/forum/forumdisplay.php?forumid=68)
-- 2° compitino, cosa abbiamo risposto? (http://www.dsy.it/forum/showthread.php?threadid=29259)

2° compitino, cosa abbiamo risposto?

Ho provato a cercare su vari testi, ma non son ancora sicuro di quale sia la risposta alla domanda del TEMA B riguardante l'MPLS.

Qualcuno si ricorda con precisione cosa chiedeva la domanda?

Se non ricordo male chiedeva cosa contenesse la tabella...

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

io ho risposto IL PATH INTERO

è giusto??????NON credo!!!!!!

Riguardo il DNS!!!!

RTO=12.52

I segmenti per 100caratteri in TCP?????
è 3 la risposta giusta??????????

io le ho tirate tutte più o meno a caso, il tema B era troppo difficile e con rossi non avevamo fatto bene quelle cose!

ma il "non-authoritive"???sul libro in ita non c'è mentre su quello inglese parla solo di records..

ribaltiamo la prof?

__________________
Het is allemaal naar de zak!!!

La ribaltiamo a calci!

per I segmenti per 100caratteri in TCP io ho risposto 10 ma con l'ack ritardato io so che il ricevitore aspetta 200msec per mandare l'ack in piggybacking ma non mi ha aiutato!
Inoltre per mpls che cos'è in italiano la backbone? Lei e il suo inglese....

anch'io ho risposto PATH INTERO alla domanda su MPLS.
Dopo un primo sguardo al Tanebaum pensavo di aver sbagliato, ma leggendo tutto il paragrafo non ne son + tanto sicuro...


Ste domande a QUIZ della patente... che palle ste sottigliezze..
Nemmeno col libro in mano so esattamente quale sia la risposta corretta...

Sul DNS non-autorithative, sempre sul Taneb dice che un record autorevole è "un record fornito dall'autorità che gestisce il record ed è sempre corretto. I record autorevoli si contrappongono ai record archiviati nella cache, che potrebbero non essere aggiornati."
E credo che la risposta sia in quest'ultima riga.

quella dell'RTO l'ho sparata proprio a caso... ho messo 10.2

Per quanto riguarda l'esercizio dei segmenti ho risposto 2

L'esercizio che chiedeva cosa contenesse la DHCP-request.. hmm al momento non ricordo la risposta che ho segnato,



PS: Backbone = Dorsale

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

e per il dhcp che avete risposto?(parlo sempre del tema B), io ho segnato la risposta col timeset....cmq è improponibile che neanche con un libro di 600 pagine in mano nn si riesca a essere certi delle soluzioni..

io ho messo che il dhcp offer è uguale al request, x' oltre all'id e all'ip scambiato vengono anke messi maschera e gateway...poi boh..

__________________
Het is allemaal naar de zak!!!

Io per rto ho messo 12.52
dhcp come poledrisk85
e per dns ho messo quando la richiesta non proveniva da un srvr. primario.
Ma cazzo! mi sembravano un pò troppo approfondite ste domande!
Metto le mani avanti: qualcuno sa se all'orale son richiesti anche gli esercizi? gracias

DHCP Request:
"Il client manda un messaggio DHCP Request, sempre all’indirizzo broadcast, indicando solo l’offerta che ha accettato [...] Il pacchetto DHCP Request contiene anche tutte le opzioni desiderate dal client. "
che praticamente non dice niente, ma cercando sul web ho trovato esempi di DHCP request:
26 Client *BROADCAST DHCP Request (xid=36773677)
Se non ricordo male c'era una risposta che diceva "l'ID del procedimento" o qualcosa di simile, cmq qualcosa tipo procedimento.

Se non ho estrapolato male il concetto, quella sembra proprio una stringa contenente un ID!!

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

per quanto riguarda i DHCP request ho messo la risposta con gli stessi parametri del DHCP offer come dice Halsall.

RTO ho messo 12.52.

Per l'MPLS ho messo porta uscita, label uscita, politica di queue (o una cosa simile). Il path intero non ha senso perchè MPLS funziona su label che hanno significato "per-hop".. almeno così ho capito!

I segmenti ho messo 10.. mi è sembrata una domanda un po' trabocchetto perchè il delayed acknowledgments ha significato solo lato server.. ossia il server aspetta 200ms prima di spedire l'ACK, e basta! Ma lato client non cambia nulla a differenza degli algoritmi di Nagle e Clark..

Per il DNS non-authorative ho messo che è la risposta di un server che ha in cache l'informazione, ma è possibile che sia obsoleta!

Speriamo...

L'esame non era affatto difficile...se si studiava...non so con Rossi, ma seguendo la Pagani lo sforzo è stato minimo (con questo non dico che Rossi sia un p...a, anzi...).

Credo di sapere alcune risposte...

DHCPrequest ripete DHCPoffer
DNS cache
RTO 12.52
MPLS output interface, label, accodamento (c'era una domanda simile anche lo scorso anno)
Acknowledgement ritardato...io ho messo 10, ma è l'unica domanda di cui non sono certo.

Le domande di teoria per chi aveva il TEMA B erano veramente una str..zata.
E anche quelle del TEMA A.

Bastava studiare, sull'Halsall però...

con rossi invece era molto più difficile perchè molte cose non le ha spiegate, o lo ha fatto in poche parole!

Originally posted by ++DeathCubeK++
L'esame non era affatto difficile...

Originally posted by ++DeathCubeK++
Le domande di teoria per chi aveva il TEMA B erano veramente una str..zata.
E anche quelle del TEMA A.

__________________
cerca di vivere non di esistere.
Se Oscar Wilde fosse ancora vivo probabilmente mi citerebbe per plagio.

Boh non so che dire...a me è sembrato più che fattibile.
Onestamente descrivere Slow Start, Congestion Avoidance e chiusura TCP (3 vie o 4) può essere un pò lungo (se fortemente dettagliato), ma non certo difficile.
Sul Arp Proxy e Split Horizont non c'era molto da dire.

Cmq ieri dopo l'esame uno a chiesto alla prof la risposta per il DNS e lei ha risposto che la risp era 10...non so se scherzava...ma forse ha ragione.
Io avevo il tema B, ma da quello che ho capito chiedeva metodo ricorsivo per dico.unimi.it

Io so che per ogni richiesta corrispondo due query (andata e ritorno) quindi i passaggi erano:
root-it-unimi-dico
quindi 4 per due query faceva 8.
In + mi sembra che c'era scritto che una richiesta era doppia e quindi ne andavano aggiunte altre due...
...non so cmq...io ho ragionato così...ma in base alla risposta 10 e a ricordi approssimativi della domanda.

Cmq credo presto la prof mettere sul jli le soluzioni.
Ciao a tutti!

il resolver in quante query risolve l 'indirizzo dico.unimi.it
dns locale dns root dns it e dns unimi ho pensato io. e siccome 8 non c'era ho messo 4. unendo i ragionamenti mi sa che è 10...
cmq io son telecomunicazioni e ho risposto per sport...
meno male

__________________
cerca di vivere non di esistere.
Se Oscar Wilde fosse ancora vivo probabilmente mi citerebbe per plagio.

le mie risposte sono state:
RTO = 12.52
HDLC = ip + id
mpls = output interface, output label,e politika di akkodamento
Akc Ritardato = 2 [questo ve lo spiego..allora produko il primo blokko e lo invio.il ricevente al posto di mandare l ack subito aspetta 200ms,in questo tempo il sender ha prodotto i restanti 9 blokki di 10caratteri (gli bastano 90ms) e all arrivo dell ack manda tutto..
c'è un esempio molto simile sulle vekkie esercitazioni..
DNS ho sparato a kaso.

Originally posted by People
le mie risposte sono state:
RTO = 12.52
mpls = output interface, output label,e politika di akkodamento
Akc Ritardato = 2 [questo ve lo spiego..allora produko il primo blokko e lo invio.il ricevente al posto di mandare l ack subito aspetta 200ms,in questo tempo il sender ha prodotto i restanti 9 blokki di 10caratteri (gli bastano 90ms) e all arrivo dell ack manda tutto..[/B]

Premetto che non ho controllato sui testi...
Comunque, la DHCP-OFFER non contiene l'ID della transazione + l'ip che viene offerto dal server?

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

OFFER: transaction_id, ip_proposto, netmask, validità

eeesatto, ricordavo anche la validità, ma della netmask ero all'oscuro.
A parte i miei pensieri delle 2 am, abbiamo capito che non erano accettabili entrambe

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

Originally posted by livio_82
A parte i miei pensieri delle 2 am, abbiamo capito che non erano accettabili entrambe

scusa eh...
Innanzitutto voglio ricordarti che la domanda verteva sulla DHCP-REQUEST.

Schematizzando:
la req contiene TRANSACTION_ID
e l'offer transaction_id, ip_proposto, netmask, validità.

Riassumento le risposte:
A) la request contiene TRANSACTION_ID (CORRETTO)
B) la request è UGUALE alla Offer (NON E' UGUALE, HA SOLO UN CAMPO DEI 4 CONTENUTI NELLA OFFER)

...

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

Hai capito male..
O almeno, i miei appunti presi al corso serale dicono che la Request e la Offer sono UGUALI.
Il client invia la Discover(ip_sorg[0.0.0.0], ip_dest[255.255.255.255], trans_id), il server risponde con una Offer(trans_id, ip_proposto, netmask, validità) e il client risponde con una Request, uguale alla Offer del server, considerata come risposta positiva ed infine l'ack inviato dal server e contenente sempre quei 4 parametri..

a me sembrava ke il client invia la rikiesta kn id e ip e il server risponde kon una Offer ke è = alla request kon + un qualkosa ke gli dika ke la rikiesta è stata accettata...

Ecco quello che so io:
Discover (client->server)
Offer (server->client)
Request (client->server)
Ack (server->client)
I parametri sono quelli che ho postato precedentemente..

Per maggiori info:
http://it.wikipedia.org/wiki/DHCP#c..._del_protocollo

la wiki italiana come sempre lascia a desiderare, comunque dalla wiki eng leggo:

"When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer".
http://en.wikipedia.org/wiki/ Dynam...election


Quindi contiene l'IP del server che ha fatto l'offerta selezionata e che quindi indentifica una specifica offerta.
Non contiene l'ip selezionato o altri dati che erano contenuti nella offer.

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

RFC 2131

The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
that MUST include the 'server identifier' option to indicate which
server it has selected, and that MAY include other options
specifying desired configuration values. The 'requested IP
address' option MUST be set to the value of 'yiaddr' in the
DHCPOFFER message from the server. This DHCPREQUEST message is
broadcast and relayed through DHCP/BOOTP relay agents. To help
ensure that any BOOTP relay agents forward the DHCPREQUEST message
to the same set of DHCP servers that received the original
DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
value in the DHCP message header's 'secs' field and be sent to the
same IP broadcast address as the original DHCPDISCOVER message.
The client times out and retransmits the DHCPDISCOVER message if
the client receives no DHCPOFFER messages.

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

Da Halsall:

DHCP Request: this is the response to the DHCP offer message and contains the same
parameters as were present in the DHCP offer message.

Sull'Halsall c'era esattamente la domanda e la risposta.
Sicuramente questa è giusta, il transiction ID...non saprei...

quello c'è sempre!!!

__________________
Het is allemaal naar de zak!!!

mhmhm sono andato a cerkare sul libro..è vero .. la request è = alla offer....
viene mandata prima una diskover..poi una offer poi una request ed invine un ack... GG

Tra le Risorse sul JLI sono uscite le risposte dei quiz..
Ci sarà da divertirsi..

porca vacca, ne ho beccate solo 2 su 5
Scandaloso
Quella del DNS e quella del numero di frame ;(

__________________
Livio

** Pone seram, cohibe, sed quis custodiet ipsos custodes? Cauta est et ab illis incipit uxor. **

www

io 3 su 5...sxo che mi vadano a culo (o di grazia) le domande..

__________________
Het is allemaal naar de zak!!!

bella 4 su 5 meno male!

mò speriamo bene x le domande!

Bueno 3 su 5 (sempre che non ho fatto casino nel segnarle)
Speriamo un pò di culo!!

Anche io 3 su 5...come pensavo!
Va beh, ora aspettiamo i risultati...ciao a tutti!

dai mi gongolo ank io.. 3 su 5 sikure giuste.. una l ho sparata a kaso speriamo sia quella giusta!!!

Sono usciti i voti sul forum del JLI..

scusate..

potreste scrivere in 2 righe come funzionano split horizon e Triggered Update?

quando sono stati spiegati non c'ero!

grazie!

Split-Horizon è una tecnica per evitare inconsistenza come nel caso del count-to-infinity. In una rete fatta così: A<->B<->C
Se A raggiunge un host C tramite il suo vicino B, quando A manda il vettore a B gli comunica che raggiunge C con metrica infinita. In questo modo se il tratto B<->C si guasta, B sa che non potrà redirigere verso A il traffico destinato a C(anche A utilizza il link guasto). In questo modo si evitano loop e congestioni, ma non in tutte le topologie di rete.

Per il Triggered-Update, credo tu ti riferisca allo scambio dei vettori, giusto?
Se è così, non è niente di che. Triggered-Update vuol dire che si ri-scambiano i vettori al verificarsi di un certo evento. Ad esempio, alla connessione di un nuovo host o al cambio di metrica. Questo velocizza l'aggiornamento ma non elimina del tutto il count-to-infinity.

Ciao.

grazie!