Dynamic Host Configuration Protocol: differenze tra le versioni

Versione delle 09:46, 26 apr 2022

Versione delle 13:45, 6 ott 2022

Riga 108:

Il DHCP garantisce l'affidabilità in diversi modi: rinnovo periodico, rebinding<ref name="Nome BOOTPS">Droms, Ralph (March 1997).[https://tools.ietf.org/html/rfc2131 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 riassociare,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.: Sese qualche altro server DHCP è in grado di rinnovare il leasing, lo farà in questo momento.

Affinché il rebinding funzioni, quando il client contatta con successo un server DHCP di backup, quel server deve disporre di informazioni accurate sull'associazione del client. Mantenere informazioni vincolanti precise tra due server è un problema complicato; se entrambi i server sono in grado di aggiornare lo stesso database di lease, deve esistere un meccanismo per evitare conflitti tra gli aggiornamenti sui server indipendenti. Una proposta per l'implementazione di server DHCP [[Tolleranza ai guasti|fault-tolerant]] è stata inviata alla Internet Engineering Task Force, ma mai formalizzata.<ref>Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003).[https://tools.ietf.org/html/draft-ietf-dhc-failover-12 DHCP Failover Protocol.] [[Internet Engineering Task Force|IETF.]] I-D draft-ietf-dhc-failover-12. Retrieved May 09, 2010.</ref>