SOCKS4 সংযোগ অনুরোধ সফল হয়, কিন্তু অ্যাপ্লিকেশনটি সার্ভারের শুরুর অভিবাদন কখনও দেখে না। দেখার একটি জায়গা হলো কানেক্টরের প্রথম পড়া। ষোলো বাইটের একটি পড়া আট বাইটের SOCKS4 প্রতিক্রিয়ার জন্য খুব বড়।

প্রতিক্রিয়ার ক্ষেত্রবাইট
প্রতিক্রিয়া সংস্করণ ক্ষেত্র1
ফলাফল কোড1
পোর্ট ক্ষেত্র2
ঠিকানা ক্ষেত্র4

ফলাফল কোড 0x5a নির্দেশ করে যে অনুরোধটি মঞ্জুর করা হয়েছে। SOCKS4a পরিবর্তন করে কীভাবে অনুরোধটি হোস্টনেম বহন করে; এটি প্রতিক্রিয়াটিকে ষোলো বাইটে পরিণত করে না।

প্রতিক্রিয়ার পরে একই TCP স্ট্রিম গন্তব্যের প্রোটোকল বহন করে। একটি মেল সার্ভার সাথে সাথেই তার অভিবাদন পাঠাতে পারে। তাই ষোলোটি উপলব্ধ বাইট গ্রহণকারী একটি পড়া সম্পূর্ণ প্রক্সি প্রতিক্রিয়া এবং সেই অভিবাদনের প্রথম আট বাইট নিয়ে নিতে পারে। যদি এখনও কিছু না আসে, অতিরিক্ত বড় ব্লকিং পড়া বরং একটি অপ্রয়োজনীয় অপেক্ষা যোগ করতে পারে।

সঠিক দৈর্ঘ্য পার্সারের দায়িত্ব

একবারে আট বাইট চাওয়া আট বাইট এসেছে তার যথেষ্ট প্রমাণ নয়। স্ট্রিম পড়া কম ফেরত দিতে পারে। একটি সময়সীমার মধ্যে প্রতিক্রিয়ার দৈর্ঘ্য ঠিকঠাক সংগ্রহ করুন, বন্ধ বা ব্যর্থ স্ট্রিমে থামুন, প্রতিক্রিয়া পরীক্ষা করুন, এবং পরবর্তী বাইটগুলি অ্যাপ্লিকেশনের জন্য রেখে দিন।

যদি কানেক্টর বড় বাফারযুক্ত পড়া ব্যবহার করে, সীমার পরের সবকিছু সংরক্ষণ করুন এবং পরবর্তী গ্রাহকের কাছে পাঠান। উদ্বৃত্ত ফেলে দেওয়া একই ডেটা ক্ষতি, শুধু ভিন্ন পড়ার আকারে।

SOCKS5-এর নিজস্ব পার্সার প্রয়োজন। ঠিকানার ধরন অনুসারে এর প্রতিক্রিয়া ঠিকানার দৈর্ঘ্য ভিন্ন হতে পারে। প্রতিটি প্রক্সি পড়াকে নির্দিষ্ট আট বাইটের পড়া দিয়ে প্রতিস্থাপন করলে একটি প্রোটোকল ঠিক হবে কিন্তু অন্যটি ভেঙে যাবে।

সম্পর্কিত নিবন্ধ