آپ کے نوٹیفائر کو اصل میں NetworkManager کی کون سی حالت ملی؟

حالت چار ایک API پر اطلاع جاری کرتی ہے اور دوسرے پر کچھ اور معنی رکھتی ہے، اور کوڈ کوئی فرق نہیں دکھاتا۔ NetworkManager میں ہر حالت کی قدر کسی نامزد گنتی سے تعلق رکھتی ہے، اور گنتیاں اس بات پر متفق نہیں کہ کسی دیے گئے عدد کا کیا مطلب ہے۔ اسی لیے کسی کام کرنے والے ٹکڑے سے صحیح عدد کو کسی دوسرے callback میں نقل کرنا رویے کی منتقلی نہیں؛ یہ ٹوٹنے کا انتظار کرتا ایک اتفاق ہے۔ پہلے قسم تلاش کریں، پھر عدد پڑھنے کے قابل ہو جاتا ہے۔

بغیر قسم کا عدد صرف افواہ ہے

یہاں دو گنتیاں اہم ہیں۔ ایک عام طور پر فعال کنکشن بیان کرتی ہے: نامعلوم، فعال کرنے والی، فعال، غیر فعال کرنے والی، غیر فعال۔ دوسری خاص طور پر VPN کنکشن بیان کرتی ہے، اور اس کے راستے میں زیادہ پڑاؤ ہیں، جن میں تیاری، کنکشن کی ترتیب، IP ترتیب اور کچھ بھی فعال ہونے سے پہلے تصدیق کی درخواست شامل ہے۔ دونوں کی گنتی دونوں صورتوں میں صفر سے شروع ہوتی ہے اور پھر الگ ہو جاتی ہے، اس لیے عام گنتی میں غیر فعال کے معنی والی قدر VPN ترتیب کے بیچ کہیں آ کر گرتی ہے۔ کوئی بھی سرخی غلط نہیں؛ وہ مختلف سوالات کا جواب دیتی ہیں۔

لفظی قدر کی بجائے نصب شدہ سرخی یا binding سے علامتی مستقل استعمال کریں۔ نام دوبارہ گنتی سے بچ جاتا ہے؛ صحیح عدد نہیں۔

مشین نہیں، ایک کنکشن پر نظر رکھیں

اس پروفائل کے UUID سے شروع کریں جو آپ کے لیے اہم ہے اور اس فعال کنکشن آبجیکٹ سے جو اس فعالیت نے بنایا تھا۔ کسی ڈیوائس کی حالت، یا کسی دوسرے ٹنل کی حالت، اس کا متبادل نہیں، چاہے دونوں ایک ہی لمحے میں بدلیں۔ مشاہدے کے ساتھ آبجیکٹ کی شناخت رکھیں، تاکہ بعد کی رپورٹ بتا سکے کہ کس پروفائل نے اسے پیدا کیا۔ مشین میں بہت سی حالتیں ہیں؛ اطلاع ان میں سے ایک کے بارے میں ہے۔

پھر طے کریں کہ اطلاع کا کیا مطلب ہونا چاہیے۔ جو کنکشن کبھی فعالیت تک نہیں پہنچا وہ ترتیب کی ناکامی ہے، اور جو سیشن فعال تھا اور پھر غائب ہو گیا وہ نقصان ہے۔ یہ الگ الفاظ کے مستحق ہیں۔

بتائیں آپ کون سی منتقلی کی رپورٹ کر رہے ہیں

نئی قدر کو الگ تھلگ جانچنے کی بجائے پچھلی حالت محفوظ کریں اور اس کا نئی سے موازنہ کریں۔ ناکام حالت میں منتقلی اور فعال حالت سے باہر نکلنا الگ واقعات ہیں، چاہے دونوں کچھ بھی جڑے بغیر ختم ہوں۔ وجہ کی تار ساتھ درج کریں، کیونکہ اکثر یہی واحد حصہ ہوتا ہے جس پر صارف کارروائی کر سکتا ہے۔

جان بوجھ کر منقطع کرنا کوئی خرابی نہیں۔ اگر اطلاع فرق نہیں پہچان سکتی، تو یہ لوگوں کو اسے نظر انداز کرنا سکھائے گی۔

ناظر کو زندہ رکھیں

نہ بدلی ہوئی حالت کے لیے بار بار پولنگ کو مزید انتباہ نہیں اٹھانا چاہیے۔ وہی ایک قاعدہ ان نوٹیفائرز کی پیدا کردہ زیادہ تر شور ہٹا دیتا ہے۔

جب مینیجر دوبارہ شروع ہو یا مشاہدہ شدہ آبجیکٹ بدلا جائے تو اس صورت کو بھی سنبھالیں۔ پرانی شناخت سے بندھا ناظر ٹھیک اسی لمحے خاموش ہو جاتا ہے جب کچھ دلچسپ ہوتا ہے، اور خاموشی صحت جیسی لگتی ہے۔ مینیجر کی موجودگی میں تبدیلی کے بعد موجودہ آبجیکٹ دوبارہ تلاش کریں، اور درج کریں کہ دوبارہ تلاش کب ہوئی۔ ورنہ لاگ صرف رپورٹ کرنا بند کرنے والا ٹنل دکھاتا ہے۔

اطلاع وہاں پہنچائیں جہاں صارف ہے

مراعات یافتہ سسٹم callback ڈیسک ٹاپ سیشن کی اطلاع کی خدمت ورثے میں نہیں پاتا۔ root سطح کے ہینڈلر سے بھیجا گیا پیغام بغیر خرابی کے غائب ہو سکتا ہے، جو ایسا نوٹیفائر بناتا ہے جو ہاتھ سے جانچنے پر کام کرتا ہے اور عملاً کبھی نہیں۔ ڈیسک ٹاپ کا مالک سیشن میں پہنچائیں، یا ڈیسک ٹاپ کے اپنے کلائنٹ کو اطلاع اٹھانے دیں۔

اگر کلائنٹ کی موجودہ اطلاع پہلے ہی یہ صورت ڈھانپتی ہے تو اسے ترجیح دیں، کیونکہ ایک واقعے کے لیے دو نوٹیفائر اضافی نہیں بلکہ معاونت کا مسئلہ ہیں۔ معاونت کے ریکارڈ میں واقعے کا وقت، پروفائل اور وجہ رکھیں، اور پاس ورڈ اور مکمل پروفائل اس سے باہر رکھیں۔ یاد رکھیں اطلاع کیا ہے: مشاہدہ شدہ حالت کی رپورٹ، نفاذ کا کوئی طریقہ نہیں، کیونکہ ٹنل نہ ہونے پر ٹریفک روکنا اپنے الگ نفاذ والی الگ پالیسی ہے۔