તરતું સરનામું પ્રોક્સી સેટિંગ સ્થિર રાખે છે: સક્રિય મશીન નિષ્ફળ જાય પછી પણ ક્લાયન્ટ એ જ હોસ્ટનામ કે IP વાપરવાનું ચાલુ રાખે છે. તે ઉપયોગી ઉપલબ્ધતા છે. પણ ચાલુ ડાઉનલોડ તો થંભી પણ શકે છે.

CONNECT ની અંદર પહેલેથી રહેલી HTTPS વિનંતી વિચારો. સક્રિય પ્રોક્સી ક્લાયન્ટ તરફનું TCP કનેક્શન અને વેબસાઇટ તરફનું બીજું કનેક્શન ધરાવે છે. તે એ સ્ટ્રીમને જોડતી એપ્લિકેશન સ્થિતિ પણ ધરાવે છે.

સરનામું સ્ટેન્ડબાય મશીન પર ખસેડવાથી પોતે જ કોઈ TCP નિયંત્રણ બ્લોક કે તે રિલે સ્થિતિ ખસતી નથી. નવો માલિક નવા કનેક્શન સ્વીકારી શકે છે, પણ જૂના માલિકે સ્થાપેલો બાઇટ પ્રવાહ ચાલુ રાખી શકતો નથી.

અપેક્ષાસામાન્ય સરનામા ફેલઓવર તે આપે છે?
એક રૂપરેખાંકિત પ્રવેશદ્વાર રાખવુંતે જ ઇચ્છિત લાભ છે
સ્થાપિત CONNECT પ્રવાહ ચાલુ રાખવોવધારાની સ્થિતિ-આધારિત યંત્રણા જરૂરી થશે
એ જ આઉટબાઉન્ડ જાહેર IP રાખવુંઆઉટબાઉન્ડ રૂટિંગ અને NAT પર આધારિત
અટકેલી એપ્લિકેશન ક્રિયા સુરક્ષિત રીતે પુનરાવર્તિત કરવીક્રિયા અને ક્લાયન્ટ પર આધારિત

VRRP ચૂંટણી અને સરનામાની માલિકી નક્કી કરે છે. તે પ્રોક્સી પ્રક્રિયા માટે પ્રતિકૃતિ પ્રોટોકોલ નથી. બીજા હાઇ-એવેલેબિલિટી સોફ્ટવેર સાથેની તૈનાતીને પણ એ જ ભેદ જોઈએ, સિવાય કે તે સ્પષ્ટપણે વધુ પૂરું પાડે.

આરોગ્ય તપાસ ખરેખર શું નિરીક્ષણ કરે છે તે તપાસો. પ્રોક્સી સેવા, DNS કે અપસ્ટ્રીમ રૂટ નિષ્ફળ હોવા છતાં મશીન જાહેરાતોનો જવાબ આપી શકે છે. ઊલટું, અતિ સંવેદનશીલ તપાસ બિનજરૂરી સ્વિચ પેદા કરી શકે છે.

ક્લાયન્ટ પુનઃપ્રાપ્તિ પણ મહત્વની છે. નવી બ્રાઉઝર વિનંતી સહેલાઈથી ફરી જોડાઈ શકે; વપરાયેલ બોડી સાથેનું અપલોડ કે નોન-આઇડેમ્પોટેન્ટ API ક્રિયાને એપ્લિકેશન-વિશિષ્ટ સંભાળની જરૂર પડી શકે. ફક્ત સ્ટેન્ડબાય દ્વારા નવી વિનંતી સફળ થઈ એટલે અદૃશ્ય ફેલઓવરનું વચન ન આપો.

સંબંધિત લેખો