libproxy मार्ग चुनता है; आपका क्लाइंट कनेक्शन बनाता है

libproxy परिणामों को प्रति-URL रूटिंग उम्मीदवारों के रूप में उपयोग करें, बजाय इसके कि खोज ऐप्लिकेशन के सॉकेट को रीडायरेक्ट कर देगी।

यदि libproxy प्रॉक्सी URI लौटाता है जबकि अगला सॉकेट सीधे कनेक्ट होता है, तो हैंडऑफ जाँचें। libproxy नीति खोजता है; यह ऐप्लिकेशन के द्वारा खोले गए हर सॉकेट को इंटरसेप्ट नहीं करता।

  1. संसाधन के लिए क्वेरी करें। प्रलेखित libproxy 0.5 C API में एक प्रॉक्सी फ़ैक्टरी बनाएँ और वास्तविक गंतव्य URL माँगें।
  2. क्रमबद्ध उम्मीदवारों की व्याख्या करें। HTTP, SOCKS और सीधे परिणामों के लिए अलग-अलग हैंडलिंग चाहिए। उनका प्राथमिकता क्रम और इच्छित विफलता नीति बनाए रखें।
  3. उपभोक्ता कॉन्फ़िगर करें। चुना गया प्रॉक्सी प्रकार, एंडपॉइंट और प्रमाणीकरण व्यवस्था ऐसे ट्रांसपोर्ट को दें जो उन्हें समर्थन देता हो। एक कच्चा TCP सॉकेट लौटाए गए URI से CONNECT या SOCKS वार्ता प्राप्त नहीं करता।

एक ही उत्तर को सभी गंतव्यों के लिए मार्ग के रूप में न सहेजें और पहला प्रॉक्सी एक बार विफल होने के कारण सीधे रूटिंग को स्थायी न बनाएँ।

यदि HTTP क्लाइंट पहले से सिस्टम प्रॉक्सी या PAC खोज को एकीकृत करता है, तो चयन का एक ही स्वामी चुनें। दो स्वतंत्र चयनकर्ता और एक और रैपर ऐसा मार्ग बना सकते हैं जो किसी भी नीति का इरादा नहीं था।

नेटिव कोड में स्थापित API की फ़ैक्टरी और परिणाम-मेमोरी जीवनचक्र का पालन करें। फ़ैक्टरी का पुन: उपयोग उपयोगी खोज स्थिति बनाए रख सकता है, लेकिन प्रत्येक गंतव्य के लिए अभी भी एक क्वेरी चाहिए। चयन को कनेक्शन परिणाम से अलग लॉग करें: लौटाया गया URI सफल प्रमाणीकरण, रिज़ॉल्यूशन या आगे की पहुँच सिद्ध नहीं करता।

संबंधित लेख