Kādu NetworkManager stāvokli jūsu paziņotājs patiešām saņēma?

Ceturtais stāvoklis vienā API izraisa paziņojumu, citā nozīmē ko citu, un kods neparāda nekādu atšķirību. Katra NetworkManager stāvokļa vērtība pieder nosauktam uzskaitījumam, un uzskaitījumi nevienojas par to, ko nozīmē dots skaitlis. Tāpēc vesela skaitļa kopēšana no strādājoša fragmenta citā atzvanīšanas funkcijā nav uzvedības pārnese; tas ir nejaušība, kas gaida salūšanu. Vispirms atrodiet tipu, un skaitlis kļūs lasāms.

Skaitlis bez tipa ir tikai bauma

Šeit svarīgi ir divi uzskaitījumi. Viens apraksta aktīvu savienojumu kopumā: nezināms, aktivizējošs, aktīvs, deaktivizējošs, deaktivizēts. Otrs apraksta konkrēti VPN savienojumu, un tam ceļā ir vairāk pieturu, tostarp sagatavošana, savienojuma iestatīšana, IP konfigurācija un autentifikācijas pieprasījums, pirms kaut kas tiek aktivizēts. To numerācija abos gadījumos sākas no nulles un pēc tam atšķiras, tāpēc vērtība, kas vispārējā uzskaitījumā nozīmē deaktivizēts, nonāk kaut kur VPN secības vidū. Neviens virsraksts nav nepareizs; tie atbild uz dažādiem jautājumiem.

Izmantojiet simbolisko konstanti no instalētā virsraksta vai sasaistes, nevis literāli. Nosaukums pārdzīvo pārnumurēšanu; veselais skaitlis ne.

Novērojiet vienu savienojumu, nevis mašīnu

Sāciet ar profila UUID, kas jūs interesē, un aktīvā savienojuma objektu, ko izveidoja šī aktivizācija. Ierīces stāvoklis vai cita tuneļa stāvoklis nav aizvietotājs, pat ja abi mainās tajā pašā mirklī. Saglabājiet objekta identitāti kopā ar novērojumu, lai vēlāks ziņojums varētu pateikt, kurš profils to radīja. Mašīnai ir daudz stāvokļu; paziņojums ir par vienu no tiem.

Pēc tam izlemiet, ko paziņojumam vajadzētu nozīmēt. Savienojums, kas nekad nesasniedza aktivizāciju, ir iestatīšanas kļūme, un sesija, kas bija aktīva un pēc tam pazuda, ir zudums. Šie ir pelnījuši dažādus vārdus.

Pasakiet, kuru pāreju jūs ziņojat

Saglabājiet iepriekšējo stāvokli un salīdziniet to ar jauno, tā vietā lai pārbaudītu jauno vērtību atsevišķi. Pāreja uz neizdevušos stāvokli un pāreja no aktīva stāvokļa ir dažādi notikumi, pat ja abi beidzas bez nekā pievienota. Pierakstiet blakus iemesla virkni, jo bieži tā ir vienīgā daļa, uz kuru lietotājs var reaģēt.

Tīša atvienošana nav kļūme. Ja paziņojums nespēj atšķirt, tas iemācīs cilvēkiem to ignorēt.

Saglabājiet novērotāju dzīvu

Atkārtota aptauja nedrīkst izraisīt vēl vienu brīdinājumu par stāvokli, kas nav mainījies. Šis viens noteikums novērš lielāko daļu trokšņa, ko rada šie paziņotāji.

Apstrādājiet arī gadījumu, kad pārvaldnieks tiek restartēts vai novērojamais objekts tiek aizstāts. Novērotājs, kas piesaistīts novecojušai identitātei, apklust tieši tajā mirklī, kad notiek kaut kas interesants, un klusums izskatās pēc veselības. No jauna atklājiet pašreizējo objektu pēc izmaiņām pārvaldnieka klātbūtnē, un pierakstiet, kad notika atklāšana no jauna. Citādi žurnāls rāda tuneli, kas vienkārši pārstāja ziņot.

Piegādājiet paziņojumu tur, kur ir lietotājs

Privilēģēts sistēmas atzvanīšanas izsaukums nemanto darbvirsmas sesijas paziņojumu pakalpojumu. Ziņojums, kas nosūtīts no root līmeņa apstrādātāja, var pazust bez kļūdas, kas rada paziņotāju, kurš darbojas, pārbaudot ar roku, un nekad praksē. Piegādājiet sesijā, kurai pieder darbvirsma, vai ļaujiet pašam darbvirsmas klientam izcelt paziņojumu.

Dodiet priekšroku esošajam klienta paziņojumam, ja tas jau aptver gadījumu, jo divi paziņotāji vienam notikumam ir atbalsta problēma, nevis liekvārdība. Saglabājiet atbalsta ierakstā notikuma laiku, profilu un iemeslu, un atstājiet ārpus tā paroles un pilnus profilus. Atcerieties, kas ir paziņojums: novērota stāvokļa ziņojums, nevis izpildes mehānisms, jo satiksmes bloķēšana, kad tuneļa nav, ir atsevišķa politika ar savu ieviešanu.