آٹھ بائٹ پڑھیں، پھر SOCKS4 ٹنل حوالے کریں
SOCKS4 جواب کی مقررہ حد کا تجزیہ کر کے منزل کا سلام نگلنے یا غیر موجود بائٹس کے انتظار سے بچیں۔
SOCKS4 کنکشن کی درخواست کامیاب ہوتی ہے، مگر ایپلیکیشن سرور کا ابتدائی سلام کبھی نہیں دیکھتی۔ دیکھنے کی ایک جگہ کنیکٹر کی پہلی پڑھائی ہے۔ سولہ بائٹ کی پڑھائی آٹھ بائٹ کے SOCKS4 جواب کے لیے بہت بڑی ہے۔
| جواب کا خانہ | بائٹس |
|---|---|
| جواب کے ورژن کا خانہ | 1 |
| نتیجہ کوڈ | 1 |
| پورٹ خانہ | 2 |
| پتہ خانہ | 4 |
نتیجہ کوڈ 0x5a ظاہر کرتا ہے کہ درخواست منظور ہوئی۔ SOCKS4a بدلتا ہے کہ درخواست ہوسٹ نام کیسے اٹھاتی ہے؛ یہ جواب کو سولہ بائٹ نہیں بناتا۔
جواب کے بعد وہی TCP اسٹریم منزل کا پروٹوکول اٹھاتی ہے۔ میل سرور اپنا سلام فوراً بھیج سکتا ہے۔ اس لیے سولہ دستیاب بائٹ استعمال کرنے والی پڑھائی پورا پراکسی جواب اور اس سلام کے پہلے آٹھ بائٹ لے سکتی ہے۔ اگر ابھی کچھ نہ آئے تو بہت بڑی بلاکنگ پڑھائی اس کے بجائے غیر ضروری انتظار بڑھا سکتی ہے۔
درست لمبائی پارسر کی ذمہ داری ہے
ایک بار آٹھ بائٹ مانگنا اس بات کا کافی ثبوت نہیں کہ آٹھ بائٹ آ گئے۔ اسٹریم پڑھائیاں کم واپس کر سکتی ہیں۔ مقررہ وقت میں جواب کی لمبائی درست جمع کریں، بند یا ناکام اسٹریم پر رکیں، جواب کا معائنہ کریں، اور اگلے بائٹس ایپلیکیشن کے لیے چھوڑ دیں۔
اگر کنیکٹر بڑی بفر پڑھائی استعمال کرتا ہے تو حد کے بعد سب کچھ محفوظ رکھیں اور اگلے صارف کو دیں۔ زائد پھینکنا مختلف پڑھائی حجم کے ساتھ وہی ڈیٹا نقصان ہے۔
SOCKS5 کو اپنا پارسر چاہیے۔ اس کے جوابی پتے کی لمبائی پتہ قسم کے مطابق مختلف ہو سکتی ہے۔ ہر پراکسی پڑھائی کو مقررہ آٹھ بائٹ کی پڑھائی سے بدلنا ایک پروٹوکول درست کرے گا مگر دوسرا توڑ دے گا۔