לקרוא שמונה בתים ואז למסור את מנהרת SOCKS4
הימנעו מלבלוע את ברכת היעד או מלהמתין לבתים שאינם קיימים על ידי ניתוח הגבול הקבוע של תגובת SOCKS4.
בקשת החיבור SOCKS4 מצליחה, אך היישום אינו רואה לעולם את ברכת הפתיחה של השרת. מקום אחד לבדוק הוא הקריאה הראשונה של המחבר. קריאה של שישה עשר בתים גדולה מדי לתגובת SOCKS4 בת שמונה בתים.
| שדה בתגובה | בתים |
|---|---|
| שדה גרסת התגובה | 1 |
| קוד תוצאה | 1 |
| שדה יציאה | 2 |
| שדה כתובת | 4 |
קוד התוצאה 0x5a מציין שהבקשה אושרה. SOCKS4a משנה את האופן שבו הבקשה נושאת שם מארח; הוא אינו הופך את התגובה לשישה עשר בתים.
לאחר התגובה, אותו זרם TCP נושא את פרוטוקול היעד. שרת דואר עשוי לשלוח את ברכתו מיד. לכן קריאה שצורכת שישה עשר בתים זמינים עלולה לקחת את תגובת ה-proxy המלאה ועוד שמונת הבתים הראשונים של אותה ברכה. אם עדיין לא מגיע דבר, קריאה חוסמת גדולה מדי עלולה דווקא להוסיף המתנה מיותרת.
אורך מדויק הוא באחריות המנתח
בקשה חד-פעמית של שמונה בתים אינה הוכחה מספקת לכך שהגיעו שמונה בתים. קריאות זרם עשויות להחזיר פחות. אספו בדיוק את אורך התגובה בתוך מועד, עצרו בזרם סגור או כושל, בדקו את התגובה, והשאירו את הבתים הבאים ליישום.
אם המחבר משתמש בקריאה מאגרית גדולה יותר, שמרו את כל מה שאחרי הגבול והעבירו אותו לצרכן הבא. השלכת העודף היא אותו אובדן נתונים בגודל קריאה אחר.
SOCKS5 זקוק למנתח משלו. אורך כתובת התגובה שלו עשוי להשתנות לפי סוג הכתובת. החלפת כל קריאת proxy בקריאה קבועה של שמונה בתים הייתה מתקנת פרוטוקול אחד ופוגעת באחר.