Jaký stav NetworkManageru váš oznamovatel vlastně dostal?

Stav čtyři spouští oznámení v jednom API a znamená něco jiného v jiném, a kód neukazuje vůbec žádný rozdíl. Každá hodnota stavu v NetworkManageru patří pojmenovanému výčtu a výčty se neshodují na tom, co dané číslo znamená. Kopírování celého čísla z fungujícího úryvku do jiného zpětného volání tedy není přenos chování; je to náhoda čekající na to, až se rozbije. Najděte nejdřív typ a číslo se stane čitelným.

Číslo bez typu je jen fáma

Důležité jsou tu dva výčty. Jeden popisuje aktivní připojení obecně: neznámé, aktivující, aktivované, deaktivující, deaktivované. Druhý popisuje konkrétně připojení VPN a má na cestě více zastávek, včetně přípravy, nastavení připojení, konfigurace IP a žádosti o ověření, než se cokoli aktivuje. Jejich číslování začíná v obou případech od nuly a pak se rozchází, takže hodnota znamenající deaktivované v obecném výčtu skončí někde uprostřed sekvence VPN. Ani jedna hlavička není špatná; odpovídají na různé otázky.

Použijte symbolickou konstantu z nainstalované hlavičky nebo vazby místo literálu. Název přežije přečíslování; celé číslo ne.

Sledujte jedno připojení, ne stroj

Začněte UUID profilu, který vás zajímá, a objektem aktivního připojení vytvořeným tímto aktivováním. Stav zařízení nebo stav jiného tunelu není náhradou, i když se oba mění ve stejný okamžik. Uchovejte identitu objektu spolu s pozorováním, aby pozdější zpráva mohla říct, který profil ho vytvořil. Stroj má mnoho stavů; oznámení se týká jednoho z nich.

Pak rozhodněte, co má oznámení znamenat. Připojení, které nikdy nedosáhlo aktivace, je selhání nastavení, a relace, která byla aktivní a pak zmizela, je ztráta. Zaslouží si různá slova.

Řekněte, který přechod hlásíte

Uložte předchozí stav a porovnejte ho s novým, místo abyste novou hodnotu zkoušeli izolovaně. Přechod do selhaného stavu a přechod z aktivovaného stavu jsou různé události, i když oba končí bez čehokoli připojeného. Zaznamenejte k tomu řetězec důvodu, protože je často jedinou částí, na kterou může uživatel reagovat.

Úmyslné odpojení není závada. Pokud oznámení nedokáže rozlišit, naučí lidi ho ignorovat.

Udržte pozorovatele naživu

Opakované dotazování nesmí vyvolat další upozornění na stav, který se nezměnil. Toto jediné pravidlo odstraní většinu šumu, který tyto oznamovatele vytvářejí.

Vyřešte také případ, kdy se správce restartuje nebo je pozorovaný objekt nahrazen. Pozorovatel vázaný na zastaralou identitu ztichne přesně ve chvíli, kdy se děje něco zajímavého, a ticho vypadá jako zdraví. Znovu objevte aktuální objekt po změně přítomnosti správce a zaznamenejte, kdy k znovuobjevení došlo. Jinak záznam ukazuje tunel, který prostě přestal hlásit.

Doručte oznámení tam, kde je uživatel

Privilegované systémové zpětné volání nedědí oznamovací službu relace plochy. Zpráva odeslaná z obsluhy na úrovni root může zmizet bez chyby, což vytvoří oznamovatel, který funguje při ručním testu a nikdy v praxi. Doručujte do relace, která vlastní plochu, nebo nechte oznámení vyvolat vlastního klienta plochy.

Dejte přednost existujícímu oznámení klienta, pokud už daný případ pokrývá, protože dva oznamovatele pro jednu událost jsou problém podpory, ne nadbytek. V záznamu podpory uchovejte čas události, profil a důvod a nechte mimo něj hesla a úplné profily. Pamatujte, co oznámení je: zpráva o pozorovaném stavu, ne donucovací mechanismus, protože blokování provozu při chybějícím tunelu je samostatná politika s vlastní implementací.