Minkä NetworkManagerin tilan ilmoittimesi oikeastaan sai?

Tila neljä laukaisee ilmoituksen yhdessä API:ssa ja tarkoittaa toisessa jotain muuta, eikä koodi näytä lainkaan eroa. Jokainen NetworkManagerin tilan arvo kuuluu nimettyyn luetteloon, eivätkä luettelot ole yksimielisiä siitä, mitä annettu luku tarkoittaa. Kokonaisluvun kopioiminen toimivasta katkelmasta toiseen takaisinkutsufunktioon ei siis ole käyttäytymisen siirtoa; se on yhteensattuma, joka odottaa rikkoutumista. Etsi ensin tyyppi, niin luvusta tulee luettava.

Luku ilman tyyppiä on vain huhu

Kaksi luetteloa on tässä tärkeää. Toinen kuvaa aktiivista yhteyttä yleisesti: tuntematon, aktivoiva, aktivoitu, deaktivoiva, deaktivoitu. Toinen kuvaa nimenomaan VPN-yhteyttä, ja siinä on enemmän pysäkkejä matkan varrella, mukaan lukien valmistelu, yhteyden asennus, IP-määritys ja todennuspyyntö ennen kuin mitään aktivoidaan. Niiden numerointi alkaa molemmissa tapauksissa nollasta ja erkanee sitten, joten yleisessä luettelossa deaktivoitua tarkoittava arvo päätyy jonnekin VPN-jakson keskelle. Kumpikaan otsikkotiedosto ei ole väärässä; ne vastaavat eri kysymyksiin.

Käytä asennetun otsikkotiedoston tai sidonnan symbolista vakiota literaalin sijaan. Nimi kestää uudelleennumeroinnin; kokonaisluku ei.

Tarkkaile yhtä yhteyttä, älä konetta

Aloita profiilin UUID:stä, joka sinua kiinnostaa, ja sen aktivoinnin luomasta aktiivisen yhteyden objektista. Laitteen tila tai toisen tunnelin tila ei ole korvike, vaikka molemmat muuttuisivat samalla hetkellä. Pidä objektin identiteetti havainnon mukana, jotta myöhempi raportti voi kertoa, mikä profiili sen tuotti. Koneella on monia tiloja; ilmoitus koskee yhtä niistä.

Päätä sitten, mitä ilmoituksen pitäisi tarkoittaa. Yhteys, joka ei koskaan saavuttanut aktivointia, on asennusvirhe, ja istunto, joka oli aktiivinen ja sitten katosi, on menetys. Ne ansaitsevat eri sanat.

Kerro, mitä siirtymää raportoit

Tallenna edellinen tila ja vertaa sitä uuteen sen sijaan, että testaisit uutta arvoa erillään. Siirtymä epäonnistuneeseen tilaan ja siirtymä pois aktivoidusta tilasta ovat eri tapahtumia, vaikka molemmat päättyvät ilman mitään yhdistettyä. Kirjaa syymerkkijono viereen, koska usein se on ainoa osa, johon käyttäjä voi vaikuttaa.

Tarkoituksellinen katkaisu ei ole vika. Jos ilmoitus ei pysty erottamaan sitä, se opettaa ihmiset jättämään sen huomiotta.

Pidä tarkkailija elossa

Toistuva kysely ei saa nostaa uutta hälytystä tilasta, joka ei ole muuttunut. Tämä yksi sääntö poistaa suurimman osan kohinasta, jota nämä ilmoittimet tuottavat.

Käsittele myös tapaus, jossa hallinta käynnistyy uudelleen tai havaittu objekti korvataan. Vanhentuneeseen identiteettiin sidottu tarkkailija vaikenee juuri sillä hetkellä, kun jotain kiinnostavaa tapahtuu, ja hiljaisuus näyttää terveydeltä. Löydä nykyinen objekti uudelleen, kun hallinnan läsnäolo muuttuu, ja kirjaa, milloin uudelleenlöytö tapahtui. Muuten loki näyttää tunnelin, joka yksinkertaisesti lakkasi raportoimasta.

Toimita ilmoitus sinne, missä käyttäjä on

Etuoikeutettu järjestelmän takaisinkutsu ei peri työpöytäistunnon ilmoituspalvelua. Root-tason käsittelijästä lähetetty viesti voi kadota ilman virhettä, mikä tuottaa ilmoittimen, joka toimii käsin testattaessa ja ei koskaan käytännössä. Toimita ilmoitus istuntoon, joka omistaa työpöydän, tai anna työpöydän oman asiakkaan nostaa ilmoitus.

Suosi asiakkaan olemassa olevaa ilmoitusta, jos se jo kattaa tapauksen, sillä kaksi ilmoitinta yhtä tapahtumaa kohti on tukiongelma eikä redundanssia. Pidä tapahtuman aika, profiili ja syy tukitietueessa ja jätä salasanat ja täydet profiilit sen ulkopuolelle. Muista, mikä ilmoitus on: raportti havaitusta tilasta, ei valvontamekanismi, koska liikenteen estäminen tunnelin puuttuessa on erillinen käytäntö, jolla on oma toteutuksensa.