আপনার অ্যাপ্লিকেশন প্রোটোকলের আগে Netty-র SOCKS নেগোশিয়েশন রাখুন
অ্যাপ্লিকেশন ট্র্যাফিকের আগে Netty SOCKS প্রক্সি হ্যান্ডলার রাখুন এবং প্রক্সি-সাইড DNS উদ্দেশ্য হলে একটি অমীমাংসিত গন্তব্য সংরক্ষণ করুন।
একটি বিদ্যমান Netty bootstrap/pipeline-এর জন্য যেখানে SOCKS সার্ভারকে গন্তব্য সমাধান করতে হবে:
bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);
pipeline.addFirst(
new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);
bootstrap.connect(
InetSocketAddress.createUnresolved("example.com", 443)
);প্রক্সি এন্ডপয়েন্ট হলো স্থানীয় পোর্ট 1080; অমীমাংসিত সংযোগ লক্ষ্য example.com:443। উভয় ভূমিকার জন্য প্রক্সি ঠিকানা ব্যবহার করবেন না এবং হ্যান্ডলার নামটি পাওয়ার আগে সমাধান করবেন না। অনুমোদিত পাবলিক-প্রক্সি পথে পাবলিক লক্ষ্যের জন্য, SOCKS5 প্রক্সি তালিকা হ্যান্ডলারের প্রক্সি এন্ডপয়েন্টের জন্য প্রার্থী সরবরাহ করে।
গন্তব্য ট্র্যাফিক বিনিময়কারী হ্যান্ডলারগুলোর আগে Socks5ProxyHandler রাখুন। এর প্রক্সি সংযোগ future-এর জন্য অপেক্ষা করুন, শুধু লিসেনারে পৌঁছানো চ্যানেলের জন্য নয়। প্রত্যাখ্যাত মেথড বা গন্তব্য এই সেটআপ পর্যায়ের অন্তর্গত।
HTTPS-এর জন্য, পরবর্তী TLS স্তর গন্তব্যের হোস্টনেম, প্রয়োজনীয় যাচাই ও বিশ্বাস ব্যবহার করে—SOCKS এন্ডপয়েন্টের পরিচয় নয়। তারপরেই HTTP/অ্যাপ্লিকেশন বিনিময় শুরু হয়।
এই অংশটি ইভেন্ট লুপ, চ্যানেল টাইপ, TLS/HTTP হ্যান্ডলার বা স্বাভাবিক ত্রুটি পরিচালনা দেয় না। প্রমাণীকরণের প্রয়োজন অনুযায়ী SOCKS কনস্ট্রাক্টর বেছে নিন; HTTP Basic হ্যান্ডলার অন্য প্রোটোকল।
no-op resolver কেবল সেখানেই ব্যবহার করুন যেখানে এই ডাউনস্ট্রিম হ্যান্ডলার হোস্টনেম সমাধানের মালিক। অন্যান্য সংযোগের স্থানীয় অনুসন্ধান প্রয়োজন হতে পারে। ত্রুটি নির্ণয়ের সময় resolver আউটপুট, প্রক্সি future, TLS এবং অ্যাপ্লিকেশন ফলাফল আলাদা রাখুন।