Dynamic Host Configuration Protocol: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Reverted edits by 91.187.215.210 (talk) to last version by UnGiglio: Annullamento di vandalismi Etichette: Rollback SWViewer [1.4] |
Etichette: Annullato Vandalismo quasi certo Possibile modifica di prova o impropria Modifica visuale |
||
Riga 106:
== Aspetti dibattuti ==
=== Affidabilità delle comunicazioni ===
ciao ian Il DHCP garantisce l'affidabilità in diversi modi: rinnovo periodico, rebinding<ref name="Nome BOOTPS">Droms, Ralph (March 1997).[rfc:2131 DHCP Options and BOOTP Vendor Extensions.] [[Internet Engineering Task Force|IETF.]] RFC 2131. Retrieved September 9, 2014.</ref> e failover. Ai client DHCP vengono assegnati leasing che durano per un certo periodo di tempo. I client iniziano a provare di rinnovare il leasing una volta che la metà dell'intervallo di lease è scaduto.<ref name="Nome BOOTPS"/> Lo fanno inviando un messaggio DHCPREQUEST in unicast al server DHCP che ha concesso il leasing originale. Se il server è inattivo o irraggiungibile,<ref name="Nome BOOTPS"/> non risponderà al DHCPREQUEST. Tuttavia, in questo caso il client ripete il DHCPREQUEST di volta in volta, quindi se il server DHCP viene ripristinato o diventa nuovamente raggiungibile, il client DHCP riuscirà a contattarlo e rinnovare il contratto di locazione.
Se il server DHCP è irraggiungibile per un lungo periodo di tempo,<ref name="Nome BOOTPS"/> il client DHCP tenterà di rinnovare l'IP trasmettendo il suo DHCPREQUEST in broadcast piuttosto che in unicast. Una volta trasmesso, il messaggio DHCPREQUEST raggiungerà tutti i server DHCP disponibili: se qualche altro server DHCP è in grado di rinnovare il leasing, lo farà in questo momento.
| |||