هشت بایت را بخوانید، سپس تونل SOCKS4 را تحویل دهید

درخواست اتصال SOCKS4 موفق می‌شود، اما برنامه هرگز سلام آغازین سرور را نمی‌بیند. یکی از جاهایی که باید نگاه کرد نخستین خواندن اتصال‌دهنده است. خواندن شانزده بایت برای پاسخ هشت‌بایتی SOCKS4 بیش از اندازه بزرگ است.

کد نتیجه 0x5a نشان می‌دهد که درخواست پذیرفته شده است. SOCKS4a شیوهٔ حمل نام میزبان در درخواست را تغییر می‌دهد؛ اما پاسخ را شانزده بایتی نمی‌کند.

پس از پاسخ، همان جریان TCP پروتکل مقصد را حمل می‌کند. یک سرور پست می‌تواند سلام خود را بی‌درنگ بفرستد. بنابراین خواندنی که شانزده بایت موجود را مصرف می‌کند می‌تواند پاسخ کامل پراکسی به‌همراه هشت بایت نخست آن سلام را بردارد. اگر هنوز چیزی در پی نیامده باشد، خواندن مسدودکنندهٔ بیش‌ازحد بزرگ می‌تواند در عوض انتظاری بی‌مورد بیفزاید.

طول دقیق مسئولیت تجزیه‌گر است

یک‌بار هشت بایت خواستن شواهد کافی برای رسیدن هشت بایت نیست. خواندن‌های جریان می‌توانند کمتر برگردانند. طول پاسخ را دقیقاً در مهلت مقرر جمع کنید، در جریان بسته یا ناموفق متوقف شوید، پاسخ را بررسی کنید و بایت‌های بعدی را برای برنامه بگذارید.

اگر اتصال‌دهنده از خواندن بافرشدهٔ بزرگ‌تر استفاده می‌کند، هر چیز پس از مرز را نگه دارید و به مصرف‌کنندهٔ بعدی بسپارید. دور ریختن مازاد همان از دست رفتن داده با اندازهٔ خواندن متفاوت است.

SOCKS5 تجزیه‌گر خودش را می‌خواهد. نشانی پاسخ آن بسته به نوع نشانی می‌تواند طول‌های متفاوت داشته باشد. جایگزین‌کردن هر خواندن پراکسی با خواندن ثابت هشت بایت یک پروتکل را درست می‌کند و پروتکل دیگر را می‌شکند.