Aký stav NetworkManageru váš oznamovateľ vlastne dostal?

Stav štyri spúšťa oznámenie v jednom API a v inom znamená niečo iné, a kód neukazuje vôbec žiadny rozdiel. Každá hodnota stavu v NetworkManageri patrí pomenovanému výčtu a výčty sa nezhodujú na tom, čo dané číslo znamená. Kopírovanie celého čísla z fungujúceho úryvku do iného spätného volania teda nie je prenos správania; je to náhoda čakajúca na to, kým sa rozbije. Nájdite najprv typ a číslo sa stane čitateľným.

Číslo bez typu je len fáma

Dôležité sú tu dva výčty. Jeden opisuje aktívne pripojenie všeobecne: neznáme, aktivujúce, aktívne, deaktivujúce, deaktivované. Druhý opisuje konkrétne pripojenie VPN a má na ceste viac zastávok, vrátane prípravy, nastavenia pripojenia, konfigurácie IP a žiadosti o overenie, kým sa čokoľvek aktivuje. Ich číslovanie sa začína v oboch prípadoch od nuly a potom sa rozchádza, takže hodnota znamenajúca deaktivované vo všeobecnom výčte skončí niekde v strede sekvencie VPN. Ani jedna hlavička nie je nesprávna; odpovedajú na rôzne otázky.

Použite symbolickú konštantu z nainštalovanej hlavičky alebo väzby namiesto literálu. Názov prežije prečíslovanie; celé číslo nie.

Sledujte jedno pripojenie, nie stroj

Začnite UUID profilu, ktorý vás zaujíma, a objektom aktívneho pripojenia vytvoreného týmto aktivovaním. Stav zariadenia alebo stav iného tunela nie je náhradou, aj keď sa oba menia v tom istom okamihu. Zachovajte identitu objektu spolu s pozorovaním, aby neskoršia správa mohla povedať, ktorý profil ho vytvoril. Stroj má veľa stavov; oznámenie sa týka jedného z nich.

Potom rozhodnite, čo má oznámenie znamenať. Pripojenie, ktoré nikdy nedosiahlo aktivovanie, je zlyhanie nastavenia, a relácia, ktorá bola aktívna a potom zmizla, je strata. Tieto si zaslúžia rôzne slová.

Povedzte, ktorý prechod hlásite

Uložte predchádzajúci stav a porovnajte ho s novým, namiesto toho, aby ste novú hodnotu skúšali izolovane. Prechod do zlyhaného stavu a prechod z aktivovaného stavu sú rôzne udalosti, aj keď oba končia bez čohokoľvek pripojeného. Zaznamenajte vedľa reťazec dôvodu, pretože často je to jediná časť, na ktorú môže používateľ reagovať.

Úmyselné odpojenie nie je porucha. Ak oznámenie nedokáže rozlíšiť, naučí ľudí ignorovať ho.

Udržte pozorovateľa nažive

Opakované dopytovanie nesmie vyvolať ďalšie upozornenie na stav, ktorý sa nezmenil. Toto jediné pravidlo odstráni väčšinu šumu, ktorý tieto oznamovatele vytvárajú.

Vyriešte aj prípad, keď sa správca reštartuje alebo je pozorovaný objekt nahradený. Pozorovateľ viazaný na zastaranú identitu stíchne presne v momente, keď sa deje niečo zaujímavé, a ticho vyzerá ako zdravie. Znovu objavte aktuálny objekt po zmene prítomnosti správcu a zaznamenajte, kedy k znovuobjaveniu došlo. Inak záznam ukazuje tunel, ktorý jednoducho prestal hlásiť.

Doručte oznámenie tam, kde je používateľ

Privilegované systémové spätné volanie nededia oznamovaciu službu relácie pracovnej plochy. Správa odoslaná z obsluhy na úrovni root môže zmiznúť bez chyby, čo vytvorí oznamovateľ, ktorý funguje pri ručnom testovaní a nikdy v praxi. Doručujte do relácie, ktorá vlastní pracovnú plochu, alebo nechajte oznámenie vyvolať vlastnému klientovi pracovnej plochy.

Uprednostnite existujúce oznámenie klienta, ak už daný prípad pokrýva, pretože dva oznamovatele pre jednu udalosť sú problém podpory, nie nadbytok. V zázname podpory uchovajte čas udalosti, profil a dôvod a nechajte mimo neho heslá a úplné profily. Pamätajte, čo oznámenie je: správa o pozorovanom stave, nie donucovací mechanizmus, pretože blokovanie prevádzky pri chýbajúcom tuneli je samostatná politika s vlastnou implementáciou.