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 ले सफल प्रमाणीकरण, समाधान वा थप पहुँच सिद्ध गर्दैन।

सम्बन्धित लेखहरू