Кое състояние на NetworkManager всъщност получи уведомителят ви?

Състояние четири задейства известие в един API и означава нещо друго в друг, а кодът не показва никаква разлика. Всяка стойност на състояние в NetworkManager принадлежи на именувано изброяване и изброяванията не са съгласни какво означава дадено число. Затова копирането на цяло число от работещ откъс в различен callback не е пренасяне на поведение; то е съвпадение, което чака да се счупи. Намерете първо типа и числото става четимо.

Число без тип е само слух

Тук има значение две изброявания. Едното описва активна връзка като цяло: неизвестно, активиране, активирано, деактивиране, деактивирано. Другото описва конкретно VPN връзка и има повече спирки по пътя, включително подготовка, настройка на връзката, конфигурация на IP и заявка за удостоверяване, преди нещо да бъде активирано. Номерацията им започва от нула и в двата случая и после се разминава, така че стойността, означаваща деактивирано в общото изброяване, попада някъде в средата на VPN последователността. Нито един от заглавните файлове не е грешен; те отговарят на различни въпроси.

Използвайте символната константа от инсталирания заглавен файл или binding, вместо литерал. Името оцелява при преномериране; цялото число — не.

Наблюдавайте една връзка, не машината

Започнете от UUID на профила, който ви интересува, и от обекта на активната връзка, създаден от това активиране. Състояние на устройство или състояние на друг тунел не е заместител, дори когато двете се променят в един и същ момент. Пазете идентичността на обекта заедно с наблюдението, за да може по-късен отчет да каже кой профил го е създал. Машината има много състояния; известието е за едно от тях.

След това решете какво трябва да означава известието. Връзка, която никога не е достигнала активиране, е провал при настройката, а сесия, която е била активна и после изчезна, е загуба. Те заслужават различни думи.

Кажете кой преход отчитате

Съхранете предишното състояние и го сравнете с новото, вместо да проверявате новата стойност изолирано. Преход към неуспешно състояние и преход от активирано състояние са различни събития, дори когато и двете завършват без нищо свързано. Записвайте и низа с причината, защото често той е единствената част, по която потребителят може да действа.

Умишленото прекъсване не е повреда. Ако известието не може да различи, то ще научи хората да го пренебрегват.

Пазете наблюдателя жив

Повтарящото се запитване не трябва да предизвиква друго предупреждение за състояние, което не се е променило. Това единствено правило премахва по-голямата част от шума, който тези уведомители създават.

Обърнете внимание и на случая, когато мениджърът се рестартира или наблюдаваният обект бъде заменен. Наблюдател, вързан към остаряла идентичност, замлъква точно в момента, когато се случва нещо интересно, а тишината изглежда като здраве. Открийте отново текущия обект след промяна в присъствието на мениджъра и запишете кога е станало преоткриването. Иначе журналът показва тунел, който просто е спрял да отчита.

Доставете известието там, където е потребителят

Привилегирован системен callback не наследява услугата за известия на сесията на работния плот. Съобщение, изпратено от манипулатор на ниво root, може да изчезне без грешка, което създава уведомител, който работи при ръчен тест и никога на практика. Доставяйте в сесията, която притежава работния плот, или оставете собствения клиент на работния плот да вдигне известието.

Предпочитайте съществуващото известие на клиента, ако то вече покрива случая, защото два уведомителя за едно събитие са проблем за поддръжката, а не излишък. Пазете времето на събитието, профила и причината в записа за поддръжка, а паролите и пълните профили оставете извън него. Помнете какво е известието: отчет за наблюдавано състояние, а не механизъм за налагане, защото блокирането на трафик при липсващ тунел е отделна политика със собствена реализация.