اقرأ ثمانية بايتات ثم سلّم نفق SOCKS4

ينجح طلب اتصال SOCKS4، لكن التطبيق لا يرى أبدًا تحية الخادم الافتتاحية. أحد الأماكن التي يجب فحصها هو أول قراءة يقوم بها الموصّل. قراءة من ستة عشر بايت أكبر من أن تناسب استجابة SOCKS4 البالغة ثمانية بايتات.

يشير رمز النتيجة 0x5a إلى أن الطلب قد قُبِل. يغيّر SOCKS4a طريقة حمل الطلب لاسم المضيف؛ لكنه لا يحوّل الاستجابة إلى ستة عشر بايتًا.

بعد الاستجابة، يحمل تدفق TCP نفسه بروتوكول الوجهة. قد يرسل خادم البريد تحيته فورًا. لذلك قد تلتقط قراءة تستهلك ستة عشر بايتًا متاحة الاستجابة الكاملة للوكيل إضافة إلى أول ثمانية بايتات من تلك التحية. وإذا لم يتبع شيء بعد، فقد تضيف قراءة حاجزة أكبر من اللازم انتظارًا غير ضروري.

الطول الدقيق مسؤولية المحلّل

طلب ثمانية بايتات مرة واحدة ليس دليلًا كافيًا على وصول ثمانية بايتات. قد تعيد قراءات التدفق أقل من ذلك. اجمع طول الاستجابة بدقة ضمن مهلة، وتوقف عند تدفق مغلق أو فاشل، وافحص الاستجابة، واترك البايتات التالية للتطبيق.

إذا استخدم الموصّل قراءة مخزّنة أكبر، فاحفظ كل ما يأتي بعد الحدّ ومرّره إلى المستهلك التالي. إن التخلص من الفائض هو الخسارة نفسها في البيانات بحجم قراءة مختلف.

يحتاج SOCKS5 إلى محلّل خاص به. فقد يختلف طول عنوان الاستجابة فيه بحسب نوع العنوان. واستبدال كل قراءة وكيل بقراءة ثابتة من ثمانية بايتات سيصلح بروتوكولًا واحدًا ويفسد آخر.