जेव्हा वेळ-आधारित PAC नियम प्रॉक्सी निवडतात
PAC मधील वेळ नियम राउटिंगचे मूल्यांकन होताना प्रॉक्सी निवडतो. तो विद्यमान कनेक्शनला अचूक सेकंदाला नवीन एक्झिटवर हलवण्याचे वचन देत नाही.
तुम्ही असा PAC नियम लिहू शकता जो सकाळी एक प्रॉक्सी आणि नंतर दुसरी परत करतो. पण त्या नियमावरून असे अनुमान काढता येत नाही की प्रत्येक विद्यमान ब्राउझर कनेक्शन दुपारी एक्झिट बदलते.
timeRange() सारखी फंक्शन्स राउटिंग निर्णयात सहभागी होतात. ती टनल बंद करणारा, सॉकेट हलवणारा किंवा प्रॉक्सी पुरवठादाराला त्याचा सार्वजनिक IP फिरवण्यास सांगणारा पार्श्वभूमी शेड्युलर नाही.
तीन घटना वेगळ्या ठेवा:
- ब्राउझर PAC चे मूल्यांकन करतो आणि मार्ग मिळवतो.
- क्लायंट त्याच्या नेटवर्किंग नियमांनुसार कनेक्शन स्थापित करतो किंवा पुन्हा वापरतो.
- निवडलेली सेवा तिच्या पुढील कनेक्शनसाठी सार्वजनिक पत्ता निवडते.
वेळेची अट थेट पहिल्या घटनेशी संबंधित आहे. आधीच सक्रिय असलेले डाउनलोड किंवा दीर्घकालीन कनेक्शन वेगळी गोष्ट आहे. क्लायंट कॅशिंग आणि कनेक्शनचा पुनर्वापर याचा अर्थ असाही की 'स्क्रिप्टमध्ये घड्याळ तपासणी आहे' हा अचूक स्विचिंग वेळापत्रकाचा पुरेसा पुरावा नाही.
जर एखाद्या कामाला प्रत्येक सत्र, विनंती किंवा वेळ-खिडकीसाठी नवीन एक्झिट हवी असेल, तर त्या गरजेसाठी तयार केलेला इंटरफेस वापरा आणि त्याचे दस्तऐवजीकृत वर्तन तपासा. PAC एंडपॉइंट्समधून निवडू शकतो, पण ते एंडपॉइंट्स त्यांच्या एक्झिट पत्त्यांसह काय करतात हे तो ठरवत नाही.
हेतुपूर्वक ठरवलेल्या नेटवर्क धोरणासाठी वेळ-आधारित राउटिंग अजूनही उपयुक्त ठरू शकते. त्याचे वर्णन मूल्यांकनाच्या वेळी मार्ग निवडणे असे करा, हमी दिलेली IP रोटेशन पद्धत असे नाही.