ستاسو خبرتیا وړونکي په رښتیا د NetworkManager کوم حالت ترلاسه کړ؟

څلورم حالت په یوه API کې خبرتیا پیلوي او په بله کې بل څه معنی لري، او کوډ هېڅ توپیر نه ښیي۔ په NetworkManager کې هر حالت ارزښت یوې نومول شوې شمېرنې ته اړه لري، او شمېرنې د دې په اړه سره نه یوځای کېږي چې یو ورکړل شوی عدد څه معنی لري۔ نو له همدې امله د یو کار کوونکي ټوټې څخه بشپړ عدد بل callback ته کاپي کول د رفتار لېږد نه دی؛ دا یو تصادف دی چې د ماتېدو په تمه دی۔ لومړی ډول پیدا کړئ، بیا عدد لوستل کېدونکی کېږي۔

بې ډوله عدد یوازې اوازه ده

دلته دوه شمېرنې مهمې دي۔ یوه په عمومي ډول فعاله اړیکه بیانوي: نامعلوم، فعالوونکی، فعال، غیر فعالوونکی، غیر فعال۔ بله په ځانګړي ډول VPN اړیکه بیانوي، او په لاره کې ډېر توقفونه لري، چې پکې چمتووالی، د اړیکې ترتیب، IP ترتیب او د یو څه فعالېدو مخکې د تصدیق غوښتنه شامله ده۔ د دواړو شمېرنه په دواړو حالتونو کې له صفر پیلېږي او بیا جلا کېږي، نو هغه ارزښت چې په عمومي شمېرنه کې غیر فعال معنی لري د VPN ترتیب په منځ کې یو چېرته ځای پرځای کېږي۔ هېڅ سرلیک غلط نه دی؛ دوی بېلو پوښتنو ته ځواب وایي۔

د لفظي ارزښت پر ځای له نصب شوي سرلیک یا binding څخه سمبوليک ثابت وکاروئ۔ نوم له بیا شمېرنې ژغورل کېږي؛ بشپړ عدد نه۔

ماشین نه، یوه اړیکه وګورئ

له هغه پروفایل UUID څخه پیل کړئ چې تاسو یې پروا لرئ او له هغه فعاله اړیکې شي څخه چې هغې فعالېدو جوړ کړی و۔ د وسیلې حالت، یا د بل تونل حالت، بدیل نه دی، حتی کله چې دواړه په یوه شیبه کې بدل شي۔ د څارنې سره د شي پیژندنه وساتئ، تر څو وروستنی راپور ووایي چې کوم پروفایل یې جوړ کړ۔ ماشین ډېر حالتونه لري؛ خبرتیا د هغو له یوه په اړه ده۔

بیا پرېکړه وکړئ چې خبرتیا باید څه معنی ولري۔ هغه اړیکه چې هېڅکله فعالېدو ته ونه رسېده د ترتیب ناکامي ده، او هغه غونډه چې فعاله وه او بیا ورکه شوه زیان دی۔ دا د بېلو کلمو وړ دي۔

ووایاست چې کوم انتقال راپور کوئ

نوی ارزښت په جلا توګه ازموئ نه، بلکې پخوانی حالت وساتئ او له نوي سره یې پرتله کړئ۔ ناکام حالت ته انتقال او له فعال حالت څخه وتل بېلې پېښې دي، حتی کله چې دواړه له هېڅ تړلي شي پرته پای ته ورسیږي۔ د دلیل تار څنګ ته ثبت کړئ، ځکه ډېری وخت یوازینی برخه ده چې کاروونکی پرې عمل کولی شي۔

په قصد بېلول تېروتنه نه ده۔ که خبرتیا توپیر ونه شي پېژندلی، نو خلک به د هغې له پام اچولو زده کړي۔

څارونکی ژوندی وساتئ

تکرارې پوښتنه باید د نه بدل شوي حالت لپاره بله خبرداری پورته نه کړي۔ هماغه یو قاعده د دې خبرتیاوو لخوا جوړ شوي ډېری شور لرې کوي۔

هغه حالت هم سمبال کړئ چې کله مدیر بیا پیل شي یا څارل شوی شی بدل شي۔ له پخواني پیژندنې سره تړلی څارونکی په سمه توګه هغه شیبه چوپېږي چې یو څه په زړه پوري پېښېږي، او چوپتیا روغتیا ته ورته ښکاري۔ د مدیر د شتون له بدلون وروسته اوسنی شی بیا ومومئ، او ثبت کړئ چې بیا موندنه کله پېښه شوه۔ که نه، لاګ یوازې هغه تونل ښیي چې راپور ورکول یې بند کړل۔

خبرتیا هلته ورسوئ چې کاروونکی هلته دی

د امتیاز لرونکې سیسټم callback د ډیسکټاپ غونډې د خبرتیا خدمت په میراث نه اخلي۔ د root کچې هندلر څخه لېږل شوی پیغام کېدای شي پرته له خطا ورک شي، چې هغه خبرتیا وړونکی جوړوي چې په لاسي ازموینه کې کار کوي او په عمل کې هېڅکله نه۔ هغې غونډې ته یې ورسوئ چې ډیسکټاپ لري، یا پرېږدئ چې د ډیسکټاپ خپل کلینټ خبرتیا پورته کړي۔

که د کلینټ موجوده خبرتیا دا حالت پخوا پوښلی وي، هغه غوره کړئ، ځکه یوه پېښې لپاره دوه خبرتیا وړونکي اضافي نه دي بلکې د ملاتړ ستونزه ده۔ په ملاتړ ریکارډ کې د پېښې وخت، پروفایل او دلیل وساتئ، او پټنومونه او بشپړ پروفایلونه ترې بهر وساتئ۔ په یاد ولرئ چې خبرتیا څه ده: د څارل شوي حالت راپور، د پلي کولو میکانیزم نه، ځکه چې د تونل نه شتون پر مهال ترافیک بندول د خپل جلا پلي کېدو سره جلا تګلاره ده۔