.NET ساکٹ کو SOCKS ہینڈ شیک کی ضرورت ہے
وضاحت کریں کہ خام .NET TCP ساکٹ کو کیا کرنا ہوگا اس سے پہلے کہ ایپلیکیشن کے بائٹس SOCKS پروکسی سے گزریں۔
SOCKS سرور کی طرف Socket.Connect() کا رخ کرنا اُس سرور سے TCP کنکشن کھولتا ہے۔ اگلے بائٹس کو پھر بھی SOCKS بولنا ہوتا ہے۔ اپنی ایپلیکیشن کا پروٹوکول فوراً بھیجنا سرور کو کسی دوسری گفتگو کے انتظار میں چھوڑ دیتا ہے۔
SOCKS5 میں کنکشن قائم کرنے میں طریقہ کار کی بات چیت، منتخب کردہ تصدیق کا تبادلہ (اگر ہو) اور منزل کا نام لینے والی درخواست شامل ہے۔ صرف کامیاب جواب ہی ایپلیکیشن کے بائٹس کے لیے راستہ کھولتا ہے۔ یہ مراحل RFC 1928 میں بیان کیے گئے ہیں۔
بات چیت کو کنکشن لیئر میں رکھیں
اپنے TCP پروٹوکول والی ایپلیکیشن ایسا کنیکٹر استعمال کر سکتی ہے جو پروکسی کو سمجھتا ہو اور قائم شدہ اسٹریم واپس دے۔ ایپلیکیشن کا باقی حصہ پھر اُس اسٹریم سے پڑھتا اور لکھتا ہے۔ کنیکٹر کو جزوی ریڈز، متغیر لمبائی کے پتے، تصدیق کی ناکامیوں اور بات چیت کے لیے مقررہ وقت کو مدنظر رکھنا چاہیے۔
ہاتھ سے لکھی گئی ایسی تنفیذ جو ایک مقررہ سائز کا بفر پڑھ کر کامیابی فرض کر لے، نازک ہوتی ہے۔ TCP SOCKS پیغامات کی حدود محفوظ نہیں رکھتا. ایپلیکیشن پروٹوکول شروع کرنے سے پہلے اُس کے ایڈریس ٹائپ کے مطابق بیان کردہ مکمل جواب پڑھیں۔ .NET 7+ کے لیے CONNECT جواب پڑھنے والا اُس مرحلے کی مثال دیتا ہے۔
اگر کوئی دیکھ بھال والی لائبریری یہ کنکشن لیئر پہلے ہی فراہم کرتی ہے تو اُس کے معاون SOCKS ورژنز، تصدیق کے طریقے اور ہدف فریم ورک چیک کریں۔ دہائی پرانا فورم لنک موجودہ مطابقت کا ثبوت نہیں بلکہ تحقیق کا نقطۂ آغاز ہے۔
HTTP کلائنٹ کی ترتیب کا دائرہ الگ ہے
HTTP کلائنٹ کی پروکسی سیٹنگ اُسی HTTP کلائنٹ کو ترتیب دیتی ہے۔ یہ عمل کے ہر خام ساکٹ کو تبدیل نہیں کرتی۔ Socket API نیٹ ورک اینڈ پوائنٹ قبول کرتا ہے اور اعلیٰ سطحی بات چیت کال کرنے والے پر چھوڑ دیتا ہے۔
خفیہ کردہ ایپلیکیشن پروٹوکول کے لیے، پروکسی ٹنل قائم ہونے کے بعد اُس کا TLS ہینڈ شیک کریں۔ اُس مرحلے پر مطلوبہ منزل کی شناخت کی تصدیق کریں۔ پروکسی کی تصدیق اور منزل کی تصدیق الگ رہتی ہیں چاہے وہ ایک ہی بنیادی اسٹریم استعمال کریں۔