જ્યારે સમય-આધારિત PAC નિયમો પ્રોક્સી પસંદ કરે છે
PAC માંનો સમય નિયમ રૂટિંગનું મૂલ્યાંકન થાય ત્યારે પ્રોક્સી પસંદ કરે છે. તે હાલના કનેક્શનને ચોક્કસ સેકન્ડે નવા એક્ઝિટ પર ખસેડવાનું વચન આપતું નથી.
તમે એવો PAC નિયમ લખી શકો છો જે સવારે એક પ્રોક્સી અને પછી બીજી પરત કરે. પણ તે નિયમથી એવું અનુમાન કરી શકાતું નથી કે દરેક હાલનું બ્રાઉઝર કનેક્શન બપોરે એક્ઝિટ બદલે છે.
timeRange() જેવા ફંક્શન રૂટિંગ નિર્ણયમાં ભાગ લે છે. તે કોઈ બેકગ્રાઉન્ડ શેડ્યુલર નથી જે ટનલ બંધ કરે, સોકેટ ખસેડે અથવા પ્રોક્સી પ્રદાતાને તેનું જાહેર IP ફેરવવાનું કહે.
ત્રણ ઘટનાઓ અલગ રાખો:
- બ્રાઉઝર PAC નું મૂલ્યાંકન કરે છે અને માર્ગ મેળવે છે.
- ક્લાયન્ટ તેના નેટવર્કિંગ નિયમો અનુસાર કનેક્શન સ્થાપિત કરે છે અથવા ફરી વાપરે છે.
- પસંદ કરેલી સેવા તેના આગળના કનેક્શન માટે જાહેર સરનામું પસંદ કરે છે.
સમયની શરત સીધી પ્રથમ ઘટનાને લગતી છે. પહેલેથી સક્રિય ડાઉનલોડ અથવા લાંબા સમયનું કનેક્શન બીજી બાબત છે. ક્લાયન્ટ કેશિંગ અને કનેક્શનનો ફરી ઉપયોગ એનો પણ અર્થ છે કે 'સ્ક્રિપ્ટમાં ઘડિયાળની ચકાસણી છે' એ ચોક્કસ સ્વિચિંગ સમયપત્રકનો પૂરતો પુરાવો નથી.
જો કોઈ કાર્યને દરેક સત્ર, વિનંતી કે સમય-વિન્ડો માટે નવું એક્ઝિટ જોઈએ, તો તે જરૂરિયાત માટે બનાવેલ ઇન્ટરફેસ વાપરો અને તેનું દસ્તાવેજીકૃત વર્તન ચકાસો. PAC એન્ડપોઇન્ટ વચ્ચે પસંદ કરી શકે છે, પણ તે એન્ડપોઇન્ટ પોતાના એક્ઝિટ સરનામાં સાથે શું કરે છે તે નિર્ધારિત કરતું નથી.
ઇરાદાપૂર્વકની નેટવર્ક નીતિ માટે સમય-આધારિત રૂટિંગ હજી ઉપયોગી થઈ શકે છે. તેને મૂલ્યાંકન સમયે માર્ગ પસંદ કરવો એમ વર્ણવો, બાંયધરીકૃત IP રોટેશન પદ્ધતિ તરીકે નહીં.