Anwani inayoelea huweka mpangilio wa proksi imara: wateja huendelea kutumia jina la mwenyeji au IP ile ile baada ya mashine inayofanya kazi kushindwa. Hiyo ni upatikanaji wenye manufaa. Hata hivyo upakuaji unaoendelea unaweza bado kusimama.

Fikiria ombi la HTTPS ambalo tayari liko ndani ya CONNECT. Proksi inayofanya kazi inamiliki muunganisho wa TCP kuelekea mteja na muunganisho mwingine kuelekea tovuti. Pia inamiliki hali ya programu inayounganisha mitiririko hiyo.

Kuhamisha anwani kwenda mashine ya akiba peke yake hakuhamishi kizuizi cha udhibiti cha TCP wala hali hiyo ya upitishaji. Mmiliki mpya anaweza kukubali muunganisho mpya bila kuweza kuendeleza mtiririko wa baiti ulioanzishwa na mmiliki wa zamani.

MatarajioJe, uhamishaji wa kawaida wa anwani unatoa hilo?
Kubakiza lango moja lililowekwaHiyo ndiyo faida inayokusudiwa
Kuendeleza mtiririko wa CONNECT ulioanzishwaItahitajika mashine ya ziada yenye hali
Kubakiza IP ile ile ya umma ya kutokaInategemea uelekezaji wa kutoka na NAT
Kurudia kwa usalama operesheni ya programu iliyokatizwaInategemea operesheni na mteja

VRRP hufafanua uchaguzi na umiliki wa anwani. Si itifaki ya urudufishaji kwa mchakato wa proksi. Usambazaji unaotumia programu nyingine ya upatikanaji wa juu unahitaji tofauti hiyo hiyo isipokuwa unatoa zaidi kwa uwazi.

Kagua kile ukaguzi wa afya unaona kwa kweli. Mashine inaweza kujibu matangazo wakati huduma yake ya proksi, DNS au njia ya juu imeshindwa. Kinyume chake, ukaguzi nyeti kupita kiasi unaweza kusababisha mabadiliko yasiyo ya lazima.

Urejeshaji wa upande wa mteja pia ni muhimu. Ombi jipya la kivinjari linaweza kuunganishwa tena kwa urahisi; upakiaji wenye mwili uliotumika au operesheni ya API isiyo idempotent inaweza kuhitaji usimamizi maalum wa programu. Usiahidi uhamishaji usioonekana kwa sababu tu ombi jipya linafanikiwa kupitia akiba.

Makala zinazohusiana