Koje je stanje NetworkManager-a vaš obavještavač zapravo dobio?

Stanje četiri pokreće obavijest na jednom API-ju i znači nešto drugo na drugom, a kod ne pokazuje nikakvu razliku. Svaka vrijednost stanja u NetworkManager-u pripada imenovanom nabrajanju, a nabrajanja se ne slažu što znači zadani broj. Zato kopiranje cijelog broja iz radnog isječka u drugi povratni poziv nije prijenos ponašanja; to je slučajnost koja čeka da se pokvari. Najprije pronađite tip i broj postaje čitljiv.

Broj bez tipa je samo glasina

Ovdje su važna dva nabrajanja. Jedno opisuje aktivnu vezu općenito: nepoznato, aktiviranje, aktivirano, deaktiviranje, deaktivirano. Drugo opisuje VPN vezu posebno i ima više zaustavljanja na putu, uključujući pripremu, postavljanje veze, IP konfiguraciju i zahtjev za autentifikaciju prije nego što se bilo što aktivira. Njihovo numeriranje počinje od nule u oba slučaja i zatim se razilazi, pa vrijednost koja znači deaktivirano u općem nabrajanju završava negdje u sredini VPN slijeda. Nijedno zaglavlje nije pogrešno; ona odgovaraju na različita pitanja.

Upotrijebite simboličku konstantu iz instaliranog zaglavlja ili povezivanja umjesto literala. Ime preživljava prenumeraciju; cijeli broj ne.

Pratite jednu vezu, ne stroj

Pođite od UUID profila koji vas zanima i objekta aktivne veze kojeg je stvorilo to aktiviranje. Stanje uređaja ili stanje drugog tunela nije zamjena, čak i kada se oboje mijenja u istom trenutku. Zadržite identitet objekta uz promatranje, kako bi kasnije izvješće moglo reći koji je profil to proizveo. Stroj ima mnogo stanja; obavijest je o jednom od njih.

Zatim odlučite što obavijest treba značiti. Veza koja nikada nije dosegnula aktiviranje je neuspjeh postavljanja, a sesija koja je bila aktivna i zatim nestala je gubitak. Oni zaslužuju različite riječi.

Recite koji prijelaz prijavljujete

Pohranite prethodno stanje i usporedite ga s novim, umjesto da novu vrijednost ispitujete izolirano. Prijelaz u neuspješno stanje i prijelaz iz aktiviranog stanja različiti su događaji čak i kada oba završe bez ičega povezanog. Zapišite i niz s razlogom, jer je često jedini dio na koji korisnik može djelovati.

Namjerno prekidanje veze nije kvar. Ako obavijest ne može razlikovati, naučit će ljude da je zanemaruju.

Održite promatrača na životu

Ponovljeno ispitivanje ne smije stvoriti još jedno upozorenje za stanje koje se nije promijenilo. To jedno pravilo uklanja većinu šuma koji ovi obavještavači stvaraju.

Obradite i slučaj kada se upravitelj ponovno pokrene ili se promatrani objekt zamijeni. Promatrač vezan uz zastarjeli identitet utihne točno u trenutku kada se dogodi nešto zanimljivo, a tišina izgleda kao zdravlje. Ponovno otkrijte trenutni objekt nakon promjene prisutnosti upravitelja i zabilježite kada se ponovno otkrivanje dogodilo. Inače zapis pokazuje tunel koji je jednostavno prestao izvještavati.

Dostavite obavijest tamo gdje je korisnik

Povlašteni povratni poziv sustava ne nasljeđuje uslugu obavijesti sesije radne površine. Poruka poslana iz rukovatelja na razini root može nestati bez pogreške, što daje obavještavač koji radi kad ga ručno testirate i nikada u praksi. Dostavite u sesiju koja posjeduje radnu površinu ili pustite vlastitog klijenta radne površine da podigne obavijest.

Preferirajte postojeću obavijest klijenta ako već pokriva slučaj, jer dva obavještavača za jedan događaj je problem podrške, a ne suvišnost. Zadržite vrijeme događaja, profil i razlog u zapisu podrške, a lozinke i potpune profile ostavite izvan njega. Zapamtite što je obavijest: izvješće o promatranom stanju, a ne mehanizam provedbe, jer blokiranje prometa dok tunel nije prisutan zasebna je politika s vlastitom implementacijom.