Xabardor qiluvchingiz aslida NetworkManager'ning qaysi holatini oldi?

To’rtinchi holat bitta API’da bildirishnoma chiqaradi, boshqasida boshqa ma’no bildiradi va kod hech qanday farq ko’rsatmaydi. NetworkManager’dagi har bir holat qiymati nomlangan sanovga tegishli va sanovlar berilgan son nimani anglatishida kelisha olmaydi. Shuning uchun ishlayotgan parçadan butun sonni boshqa callbackga ko’chirish xatti-harakatni uzatish emas; bu buzilishni kutayotgan tasodif. Avval turni toping, shunda son o’qiladigan bo’ladi.

Tursiz son faqat mish-mish

Bu yerda ikkita sanov muhim. Biri faol ulanishni umuman tasvirlaydi: noma’lum, faollashtiruvchi, faol, o’chiruvchi, o’chirilgan. Ikkinchisi xususan VPN ulanishini tasvirlaydi va yo’lda ko’proq to’xtash joylari bor, jumladan tayyorlash, ulanishni sozlash, IP konfiguratsiyasi va biror narsa faollashishidan oldin autentifikatsiya so’rovi. Ularning raqamlanishi ikkala holatda ham noldan boshlanadi va keyin ajraladi, shuning uchun umumiy sanovda o’chirilgan ma’nosini beradigan qiymat VPN ketma-ketligining o’rtasida bir joyga tushadi. Ikkala sarlavha ham noto’g’ri emas; ular turli savollarga javob beradi.

Literal o’rniga o’rnatilgan sarlavha yoki bog’lanishdan ramziy konstantadan foydalaning. Nom qayta raqamlashdan omon qoladi; butun son qolmaydi.

Mashinani emas, bitta ulanishni kuzating

Sizni qiziqtirgan profil UUID’sidan va o’sha faollashtirish yaratgan faol ulanish obyektidan boshlang. Qurilma holati yoki boshqa tunnel holati uning o’rnini bosmaydi, ikkalasi bir vaqtning o’zida o’zgarsa ham. Kuzatish bilan birga obyektning o’ziga xosligini saqlang, keyingi hisobot qaysi profil uni yaratganini ayta olishi uchun. Mashinada holatlar ko’p; bildirishnoma ulardan biri haqida.

Keyin bildirishnoma nimani anglatishi kerakligini hal qiling. Faollashtirishga hech qachon yetmagan ulanish — sozlash muvaffaqiyatsizligi, faol bo’lib keyin yo’qolgan sessiya esa yo’qotish. Bular turli so’zlarga loyiq.

Qaysi o’tishni xabar qilayotganingizni ayting

Yangi qiymatni alohida sinash o’rniga oldingi holatni saqlang va uni yangisi bilan solishtiring. Muvaffaqiyatsiz holatga o’tish va faol holatdan chiqish har xil hodisalar, ikkalasi ham hech narsa ulanmagan holda tugasa ham. Sabab satrini yoniga yozib qo’ying, chunki ko’pincha foydalanuvchi harakat qila oladigan yagona qism shu.

Ataylab uzish nosozlik emas. Agar bildirishnoma farqni ajrata olmasa, u odamlarga uni e’tiborsiz qoldirishni o’rgatadi.

Kuzatuvchini tirik tuting

Takroriy so’rov o’zgarmagan holat uchun yana bir ogohlantirish chiqarmasligi kerak. Shu bitta qoida bu xabardor qiluvchilar keltiradigan shovqinning katta qismini olib tashlaydi.

Menejer qayta ishga tushganda yoki kuzatilayotgan obyekt almashtirilganda ham shu holatni ko’rib chiqing. Eskirgan o’ziga xoslikka bog’langan kuzatuvchi qiziqarli narsa sodir bo’layotgan aynan shu paytda jim qoladi va sukunat sog’liqday ko’rinadi. Menejerning mavjudligi o’zgargandan keyin joriy obyektni qayta toping va qayta topish qachon sodir bo’lganini yozib qo’ying. Aks holda jurnal shunchaki hisobot berishni to’xtatgan tunnelni ko’rsatadi.

Bildirishnomani foydalanuvchi turgan joyga yetkazing

Imtiyozli tizim callbacki ish stoli sessiyasining bildirishnoma xizmatini meros olmaydi. root darajasidagi ishlov beruvchidan yuborilgan xabar xatosiz yo’qolishi mumkin, bu esa qo’lda sinovdan o’tkazganda ishlaydigan va amalda hech qachon ishlamaydigan xabardor qiluvchini yaratadi. Ish stoliga ega sessiyaga yetkazing yoki ish stolining o’z mijozi bildirishnomani ko’tarsin.

Mijozning mavjud bildirishnomasi bu holatni allaqachon qamrab olsa, uni afzal ko’ring, chunki bitta hodisa uchun ikkita xabardor qiluvchi ortiqchalik emas, qo’llab-quvvatlash muammosi. Qo’llab-quvvatlash yozuvida hodisa vaqti, profil va sababni saqlang, parollar va to’liq profillarni undan tashqarida qoldiring. Bildirishnoma nima ekanini eslang: kuzatilgan holat hisoboti, ijro mexanizmi emas, chunki tunnel yo’qligida trafikni bloklash o’z amalga oshirilishiga ega alohida siyosat.