టన్నెల్ చనిపోతున్నప్పుడు కూడా మీ అప్లికేషన్ పని చేస్తూనే ఉంటుంది. Wi-Fi ఇంకా ఆన్‌లో ఉంది, ఇంటర్నెట్ ఇంకా సమాధానం ఇస్తోంది, మరియు అప్లికేషన్ ఆధారపడే ప్రైవేట్ API అందుబాటులో లేకుండా పోయింది. ప్రజలు ఇక్కడ సాధారణంగా ఆశ్రయించే .NET ఈవెంట్, NetworkAvailabilityChanged, ఆ పరిస్థితిని అసలు వివరించదు. అది మెషీన్ మొత్తం స్థితిలో మార్పును నివేదిస్తుంది, మరియు VPN డిస్‌కనెక్ట్, తిరిగి కనెక్ట్ అయ్యే సమయంలోనూ ఆ స్థితి నిజంగా ఉండవచ్చు. పరిశీలకుడు టన్నెల్‌ను కలిగి ఉన్న క్లయింట్‌ను గమనించాలి, నెట్‌వర్క్ స్టాక్ సారాంశాన్ని కాదు.

లభ్యత అనేది మొత్తం విలువ, మీ టన్నెల్ కాదు

NetworkAvailabilityChanged మెషీన్ మొత్తం లభ్యత సమాధానం మారినప్పుడు ప్రేరేపించబడుతుంది, మరియు ఆ సమాధానం loopback లేదా టన్నెల్ తప్ప ఏదైనా క్రియాశీల ఇంటర్‌ఫేస్‌ను లెక్కిస్తుంది.

Wi-Fi ఆన్‌లో ఉన్నప్పుడు VPN పడిపోవడం అది కొలిచే దేన్నీ మార్చదు, అందుకే మీకు ముఖ్యమైన ఆ వైఫల్యం సమయంలోనే ఈవెంట్ నిశ్శబ్దంగా ఉండవచ్చు.

స్థితి స్ట్రీమ్ టన్నెల్ యాజమాన్య క్లయింట్‌కు చెందుతుంది

ఏ కాంపోనెంట్ కనెక్షన్‌ను కలిగి ఉందో గుర్తించండి: OpenVPN GUI లేదా సేవ, OpenVPN Connect, లేదా మీ అప్లికేషన్ ప్రారంభించి నియంత్రించే ప్రక్రియ. ఇవి వేర్వేరు మద్దతు ఇంటర్‌ఫేస్‌లు కలిగిన వేర్వేరు యజమానులు, మరియు పరిశీలకుడు అమలుకు సరిపోయేది ఉపయోగించాలి. మీరు సమన్వయం చేసుకోవడానికి అధికారం ఉన్న OpenVPN ప్రక్రియకు, నిర్వహణ ఇంటర్‌ఫేస్ ప్రస్తుత స్థితి, చరిత్ర మరియు నిజ-సమయ నోటిఫికేషన్‌లను నివేదిస్తుంది. స్థానికీకరించిన GUI శీర్షికలో connected పదాన్ని వెతకడం బదులు డాక్యుమెంట్ చేసిన నిర్మాణాత్మక సందేశాలను విశ్లేషించండి.

నిర్వహణ ఛానెల్ ప్రత్యేక నియంత్రణ ఉపరితలం, కాబట్టి కొత్త శ్రోతను తెరవద్దు మరియు GUI ఇప్పటికే కలిగి ఉన్న ఛానెల్ కోసం దానితో గొడవ పడకండి.

తరం కాపలాదారులు పాత ఫలితాలను ఆపుతారు

ప్రతి పరిశీలన నిర్దిష్ట కనెక్షన్ ప్రయత్నానికి చెందుతుంది. కొత్త ప్రయత్నం ప్రారంభమైనప్పుడు, ఛానెల్ పోయినప్పుడు, క్లయింట్ నిష్క్రమణను నివేదించినప్పుడు తరం కౌంటర్ పెంచండి.

A కనెక్షన్ సమయంలో ప్రారంభమైన పరిశీలనను పరిగణించండి. టన్నెల్ పడిపోతుంది, B కనెక్షన్ ప్రారంభమవుతుంది, ఆ తర్వాత A ఆలస్యమైన HTTP విజయం వస్తుంది. కాపలాదారు లేకపోతే ఆ పాత ఫలితం B ఇంకా ధృవీకరిస్తున్నప్పుడే డిస్‌ప్లేను ఆకుపచ్చగా చేస్తుంది. రద్దు వృథా పనిని తగ్గిస్తుంది, మరియు తరం తనిఖీయే పాత పూర్తిని ప్రస్తుత స్థితి కాకుండా ఆపుతుంది:

var generation = _generation;
var reachable = await ProbeAsync(token);
if (generation != _generation) return;
Publish(reachable);

UI పంపిణీ చుట్టూ అదే నియమాన్ని వర్తించండి, ఎందుకంటే మార్షల్ చేసిన అప్‌డేట్ తరం ముందుకు వెళ్లిన తర్వాత కూడా రావచ్చు.

ప్రారంభం మరియు తిరిగి కనెక్ట్ ఒకే జీవిత చక్రం

మొదటి కనెక్షన్, తిరిగి కనెక్ట్ మరియు ఛానెల్ నష్టాన్ని ఒకే నియమ సముదాయంతో ఒకే జీవిత చక్రంగా పరిగణించండి:

  • ఇంటర్‌ఫేస్ అనుమతించిన చోట ఒకే దశలో ప్రస్తుత స్థితిని చదివి నోటిఫికేషన్‌లకు సభ్యత్వం తీసుకోండి.
  • ప్రతి పరిశీలనను కనెక్షన్ గుర్తింపు మరియు తరంతో ట్యాగ్ చేయండి.
  • తిరిగి కనెక్ట్, నిష్క్రమణ లేదా పోయిన పరిశీలన ఛానెల్‌లో సిద్ధతను చెల్లదని చేయండి.
  • యజమాని ప్రారంభం పూర్తయిందని నివేదించిన తర్వాత మాత్రమే ప్రైవేట్ వనరును పరిశీలించండి.
  • ఇప్పటికీ ప్రస్తుత తరానికి చెందిన ఫలితాలను మాత్రమే ప్రచురించండి.

పోయిన ఛానెల్ అంటే తెలియదు, డిస్‌కనెక్ట్ కాదు. తెలియదని నివేదించడం మీరు నిరూపించలేని డిస్‌కనెక్ట్‌ను నివేదించడం కంటే నిజాయితీగా ఉంటుంది, మరియు తిరిగి ప్రయత్నించే తర్కం ఊహపై పనిచేయకుండా ఆపుతుంది.

సాక్ష్యాలను నివేదించండి, బూలియన్ కాదు

పేరున్న సెషన్ స్థితి మరియు వనరు సిద్ధతను వేర్వేరు విలువలుగా తిరిగి ఇవ్వండి, ప్రతిదానికి వయస్సు ఉంటుంది. ఏదో నిర్ణయించుకోవాల్సిన వినియోగదారు చివరి విజయవంత పరిశీలన నలభై సెకన్ల వయస్సు ఉందని చూడగలరు, ఇది తాజా సమాచారం నుండి భిన్నమైన సమాచారం.

ప్రజా IP శోధన అనేది ప్రైవేట్ API అవసరమైన మార్గాన్ని ఉపయోగించిందనడానికి సాక్ష్యం కాదు, కాబట్టి అలా ఉన్నట్టు ప్రదర్శించకండి.

అమలును పరిశీలకుడి వెలుపల ఉంచండి

కాల్‌బ్యాక్ సంఘటన తర్వాత నడుస్తుంది. సంఘటన మరియు హ్యాండ్లర్ మధ్య మెషీన్ నుండి ఏ ప్యాకెట్ బయటకు వెళ్లలేదని అది హామీ ఇవ్వలేదు. డిజైన్‌కు నిరోధం అవసరమైతే, నెట్‌వర్కింగ్ విధానమే దాన్ని ఇవ్వాలి, మరియు పరిశీలకుడి పని తన కాలర్‌కు సాక్ష్యాలను వివరించడం. రెండింటినీ కలపడం బూలియన్ కలిగి ఉన్నందున తనను ఫైర్‌వాల్ అనుకునే కోడ్‌ను సృష్టిస్తుంది. అమలు పొరను బోరింగ్‌గా మరియు పరీక్షించదగినదిగా ఉంచండి, పరిశీలకుడు పాఠకుడిగానే ఉండనివ్వండి.

అప్పుడు UI ప్రశ్న సులభమవుతుంది: తెలిసినదాన్ని దాని వయస్సుతో చూపండి, మరియు తెలియనప్పుడు తెలియదని చెప్పండి.

సంబంధిత వ్యాసాలు