چیٹ صفحہ کھلتا ہے مگر لائیو کنکشن ناکام ہوتا ہے: کہاں دیکھیں
صفحہ اور چیٹ کی ترسیل الگ الگ درخواستیں ہیں۔ WebSocket، واقعات کی روانی یا طویل پول جانچیں، پھر ترتیب، ترسیل اور عمر کو الگ کریں۔
چیٹ صفحہ لوڈ کرنے سے پہلے نیٹ ورک پینل کھولیں، پھر وہ درخواست تلاش کریں جو پیغامات لے کر جاتی ہے، نہ کہ وہ جو صفحے کا ڈھانچہ بناتی ہے۔ دستاویز، اسکرپٹس، سائن اِن کے وقت کا تبادلہ اور چیٹ کی ترسیل سب مختلف میزبانوں کی طرف جا سکتے ہیں۔ VPN نے چیٹ خراب کی، ایسی زیادہ تر رپورٹیں دراصل اِن چار میں سے ایک درخواست کی ناکامی بیان کرتی ہیں۔ اِنہیں ترتیب سے دیکھیں اور جواب عموماً پہلے دو منٹ میں نظر آتا ہے۔
وہ درخواست تلاش کریں جو پیغامات لے کر جاتی ہے
صفحہ پرسکون ہونے پر قسم کے مطابق چھانٹیں: WebSocket الگ اندراج کے طور پر آتا ہے، واقعات کی روانی بڑھتے جواب کے ساتھ کھلی رہتی ہے، اور طویل پول مقررہ وقفے سے دہرایا جاتا ہے۔ جو اندراج تازہ کاریاں لے کر جاتا ہے اُس کے لیے اسکیم، میزبان، پورٹ اور حالت ریکارڈ کریں۔ نوٹ کریں کہ یہ سائن اِن سے پہلے یا بعد شروع ہوا، کیونکہ تصدیق سے پہلے کھلی ترسیل عموماً بعد میں کھلی ترسیل سے مختلف ڈیزائن ہوتی ہے۔ اپ گریڈ درخواست یا قبول شدہ مواد کی قسم کے لیے درخواست کے ہیڈر پڑھیں، کیونکہ وہی اُس ترسیل کی نشاندہی کرتے ہیں جو تعینات صفحے نے واقعی چنی۔
پرانی فورم پوسٹیں ایسی ترسیل بیان کرتی ہیں جو مصنوعات نے برسوں پہلے چھوڑ دیں، لہٰذا مضمون پر نہیں، براؤزر کے ریکارڈ پر بھروسہ کریں۔ اگر اندراج بالکل نہ ہو تو ممکن ہے کلائنٹ کوڈ نے کبھی کنکشن کی کوشش ہی نہ کی ہو، جو پہلے کی اسکرپٹ یا ترتیب کی ناکامی کی طرف اشارہ کرتا ہے۔ صفحے کا لوڈ ہونا صرف یہ ثابت کرتا ہے کہ دستاویز پہنچی، اور یہی فرق طے کرتا ہے کہ آپ واقعی نیٹ ورک ڈی بگ کر رہے ہیں یا نہیں۔
ترتیب، ترسیل اور عمر مختلف طریقوں سے ناکام ہوتی ہیں
WebSocket ایچ ٹی ٹی پی اپ گریڈ سے کھلتا ہے جس کا جواب 101 حیثیت سے دیا جاتا ہے، اور اُس کے بعد سب کچھ صفحہ کھینچنا نہیں بلکہ فریم شدہ پیغامات ہیں؛ یہ دو مرحلے RFC 6455 واضح طور پر الگ رکھتا ہے۔ واقعات کی روانی اسٹریمنگ مواد کی قسم سے جواب دیتی ہے اور جواب کا جسم کھلا رکھتی ہے۔ دونوں کھل نہ سکیں، کھلیں اور کچھ نہ پہنچائیں، یا کھلیں، پہنچائیں اور پھر خاموشی سے مر جائیں۔
wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events
پروفائل کو چھونے سے پہلے پہلی بامعنی ناکامی پکڑیں، کیونکہ وہ تین اوقات الگ تہوں کی طرف اشارہ کرتے ہیں۔ اگر ہاتھ ملانا کبھی مکمل نہ ہو تو اُسے اُسی میزبان کی سادہ HTTPS درخواست سے موازنہ کریں کہ آیا کچھ وہاں پہنچتا ہے یا نہیں۔ اگر مکمل ہو اور پیغامات نہ آئیں تو دوسرے اکاؤنٹ سے آزمائشی پیغام بھیجتے وقت فریم یا روانی کا جسم دیکھیں۔ اگر کام کرے اور پھر رک جائے تو درست وقت اور بند ہونے کا کوڈ ریکارڈ کریں، کیونکہ یہی جوڑی بتاتی ہے کہ کون سی طرف ہاری۔
کوڈ 1006 کا مطلب ہے کہ ساکٹ بند کرنے والے فریم کے بغیر بند ہوا، اور بیچ کا آلہ یا بیکاری کا ٹائم آؤٹ براؤزر کے اندر سے ایسا ہی دکھائی دیتا ہے۔ VPN کی دھڑکن یہ ثابت نہیں کرتی کہ اندر کا ایپلیکیشن سیشن اب بھی زندہ ہے۔
لائیو میزبان ایک الگ منزل ہے
چیٹ کے بیک اینڈ اکثر اپنے ہی میزبان نام پر رہتے ہیں، کبھی کسی اور پورٹ پر یا الگ سرٹیفکیٹ کے پیچھے۔ اُس منزل کو اپنی ریزولوشن، راستہ اور پراکسی کی کارروائی چاہیے، اور تقسیم شدہ ٹنل صفحہ شامل کر کے ساکٹ نکال سکتا ہے۔ کلائنٹ مشین سے لائیو میزبان نام حل کریں اور تصدیق کریں کہ وہ اُس نیٹ ورک پر آپ کے متوقع پتے سے جواب دیتا ہے۔ سرٹیفکیٹ کا سلسلہ خاص طور پر اُسی میزبان نام کے لیے جانچیں، کیونکہ سائٹ کو ڈھانپنے والا وائلڈ کارڈ ہمیشہ ساکٹ کے آخری نقطے کو نہیں ڈھانپتا۔
اگر راستے میں پراکسی ہو تو تصدیق کریں کہ وہ اپ گریڈ یا طویل جواب کی اجازت دیتی ہے، بجائے اُسے بفر کرنے کے۔ ایچ ٹی ایم ایل دوبارہ لکھنے والی کارپوریٹ پراکسیاں WebSocket اپ گریڈ کو اکثر بری طرح سنبھالتی ہیں، جس سے صفحہ بنتا ہے مگر چیٹ کبھی جڑتا نہیں۔ اِس لیے ایک ہی مصنوعات کی دو درخواستیں ایک ہی میزبان کی دو درخواستیں نہیں ہیں۔
منازل کی فہرست درست کریں، سیکیورٹی جانچیں نہیں
منازل کی فہرست درست کرنا راستے کی تبدیلی ہے اور راستے کے مالک کا کام ہے۔ سرٹیفکیٹ کی توثیق نرم کرنا یا Origin ہیڈر ہٹانا سیکیورٹی کی تبدیلی ہے اور پالیسی کے مالک کا کام ہے، جو کم ہی ٹکٹ ڈی بگ کرنے والا شخص ہوتا ہے۔ کنکشن کو کامیاب دکھانے کا تیز ترین طریقہ عموماً واقعہ کو ممکن بنانے کا تیز ترین طریقہ ہوتا ہے۔
کچھ بھی بدلنے سے پہلے ایپلیکیشن کے مالک سے پوچھیں کہ بیک اینڈ کون سے ماخذ قبول کرتا ہے، اور وہ جواب پراکسی کنٹرول کرنے والے کو دیں۔ اگر سرٹیفکیٹ کی خرابی صرف ٹنل سے ظاہر ہو تو بائی پاس لگانے کے بجائے روکنے والے آلے کی جانچ کریں۔
حوالے کرنے کے لیے کافی ریکارڈ کریں
کارآمد ریکارڈ مختصر ہوتا ہے: صفحے کا URL، لائیو آخری نقطہ، ہاتھ ملانے کا نتیجہ، پہلی ناکامی کا وقت اور یہ کہ دوبارہ جڑنے کی کوشش ہوئی یا نہیں۔ VPN پروفائل کا نام اور وہ نیٹ ورک شامل کریں جس پر آپ تھے، پھر پڑھنے والا کوئی بھی چھ سوال پوچھے بغیر آزمائش دہرا سکتا ہے۔ کوکیز، اجازت کے ہیڈر اور پیغامات کا جسم چھپائیں، اور مکمل آرکائیو برآمد کے بجائے وقت کے کالم کا اسکرین شاٹ چنیں۔ فریم اور نیٹ ورک آرکائیو میں نجی پیغامات اور سیشن ٹوکن ہو سکتے ہیں، لہٰذا کچھ منسلک کرنے سے پہلے جانچیں۔
اگر ناکامی خاموش بندش ہو تو بند ہونے کا کوڈ اور اُس سے پہلے کی بیکاری کی مدت شامل کریں، کیونکہ یہی جوڑی عموماً ٹائم آؤٹ کے مالک کی نشاندہی کرتی ہے۔ ٹائم آؤٹ کی قدر خود اندازہ لگانے کے بجائے ریکارڈ ایپلیکیشن یا گیٹ وے کے مالک کے حوالے کریں۔ معاونت یافتہ keepalive رویے کے بارے میں اُن کا جواب ہی ٹکٹ بند کرنے والا جواب ہے۔