.dsy:it. - 2° compitino, cosa abbiamo risposto?

Pages (4): « 1 2 [3] 4 »
Show 150 posts per page

.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)

Posted by livio_82 on 06-02-2007 12:05:

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

Posted by livio_82 on 06-02-2007 12:14:

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.

http://www.ietf.org/rfc/rfc2131.txt

Diciamo che l'RFC in parte mi rassicura, in parte mi fa venire qualche piccolo dubbio...

Continuando nella lettura dell'RFC ci son altri punti che andrebbero quotati e valutati, ma provo a sbattere la testa in qualche altro loco.

__________________
Livio

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

www

Posted by ++DeathCubeK++ on 06-02-2007 17:14:

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...

Posted by poledrisk85 on 06-02-2007 19:18:

quello c'è sempre!!!

__________________
Het is allemaal naar de zak!!!

Posted by People on 08-02-2007 08:57:

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

Posted by nytro on 09-02-2007 15:03:

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

Posted by livio_82 on 10-02-2007 00:12:

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

Posted by poledrisk85 on 10-02-2007 08:31:

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

__________________
Het is allemaal naar de zak!!!

Posted by stehouse on 10-02-2007 16:38:

bella 4 su 5 meno male!

mò speriamo bene x le domande!

Posted by Andrej on 10-02-2007 22:04:

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

Posted by ++DeathCubeK++ on 12-02-2007 09:36:

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

Posted by People on 12-02-2007 12:22:

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

Posted by nytro on 12-02-2007 13:00:

Sono usciti i voti sul forum del JLI.. :evil:

Posted by GiKappa on 12-02-2007 19:05:

scusate..

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

quando sono stati spiegati non c'ero!

grazie!

Posted by nytro on 12-02-2007 19:28:

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.

All times are GMT. The time now is 21:37.

Pages (4): « 1 2 [3] 4 »
Show all 46 posts from this thread on one page