একটি লুপ SOCKS উত্তরের আটটি বাইট চায়। সে তিনটি পেয়েছে। পরের রিড b'' ফেরত দেয়, লুপ সেটি যোগ করে, দৈর্ঘ্য যাচাই করে এবং চিরকাল আবার চেষ্টা করে।

এটি EOF হ্যান্ডলিংয়ের বাগ, দীর্ঘতর টাইমআউট দরকার হওয়া ধীর প্রক্সি নয়। স্বাভাবিক স্ট্রিম-সকেট রিসিভে খালি বাইট স্ট্রিং মানে পিয়ার সংযোগ বিচ্ছিন্ন করেছে। বাকি পাঁচটি বাইট ওই সংযোগে আসবে না।

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

ক্রিয়ার আগে সকেটের অভীষ্ট টাইমআউট সেট করুন এবং প্রক্সি প্রোটোকল নির্দিষ্ট ক্ষেত্রের দৈর্ঘ্য পড়ুন। একটি রিসিভ উত্তরের কেবল একটি অংশ ফেরত দিতে পারে। উল্টোদিকে, বড় নির্দিষ্ট বাফার চাওয়া মানে এই নয় যে প্রতিটি SOCKS ঠিকানার ওই দৈর্ঘ্য হবে।

পুরনো MSG_WAITALL স্নিপেট উৎসে পেস্ট করে এবং সেটি EOF, সিগন্যাল ও প্ল্যাটফর্ম আচরণ ঢাকে ধরে নিয়ে নির্ভরতা ঠিক করবেন না। রক্ষণাবেক্ষণ করা বাস্তবায়নের সমর্থিত সমাধান বেছে নিন, বা পার্সার আপনার কোড হলে হেল্পারের চুক্তি সচেতনভাবে বাস্তবায়ন করুন।

কত বাইট প্রত্যাশিত ও প্রাপ্ত ছিল তা রাখুন, ক্রেডেনশিয়াল পেলোড লগ না করে। “আটটি উত্তরের বাইটের তিনটির পরে EOF” ভাঙা আদান-প্রদানকে “প্রক্সি আবার আটকে গেল”-এর চেয়ে অনেক ভালোভাবে ব্যাখ্যা করে।

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