Bildirişiniz əslində NetworkManager-in hansı vəziyyətini aldı?

Dördüncü vəziyyət bir API-də bildiriş yandırır, digərində isə başqa məna daşıyır və kod heç bir fərq göstərmir. NetworkManager-dəki hər vəziyyət dəyəri adlandırılmış sadalamaya aiddir və sadalamalar verilmiş ədədin nə demək olduğu barədə razılaşmır. Ona görə də işləyən bir fraqmentdən tam ədədi başqa geri çağırış funksiyasına köçürmək davranışın ötürülməsi deyil; qırılmağı gözləyən bir təsadüfdür. Əvvəlcə tipi tapın, sonra ədəd oxunaqlı olur.

Tipsiz ədəd yalnız şaiədir

Burada iki sadalama vacibdir. Biri ümumiyyətlə aktiv bağlantını təsvir edir: naməlum, aktivləşdirən, aktivləşmiş, deaktivləşdirən, deaktiv. Digəri xüsusi olaraq VPN bağlantısını təsvir edir və yol boyunca daha çox mərhələ var: hazırlıq, bağlantının qurulması, IP konfiqurasiyası və hər hansı şey aktivləşməzdən əvvəl autentifikasiya sorğusu. Onların nömrələnməsi hər iki halda sıfırdan başlayır, sonra ayrılır, buna görə ümumi sadalamada deaktiv mənasını verən dəyər VPN ardıcıllığının ortasında bir yerə düşür. Heç bir başlıq səhv deyil; onlar fərqli suallara cavab verir.

Hərfi dəyər yerinə quraşdırılmış başlıqdan və ya bağlamadan simvolik sabiti istifadə edin. Ad yenidən nömrələnmədən sağ çıxır; tam ədəd isə yox.

Maşını deyil, bir bağlantını izləyin

Sizi maraqlandıran profil UUID-dən və həmin aktivləşdirmənin yaratdığı aktiv bağlantı obyektindən başlayın. Cihaz vəziyyəti və ya başqa tunelin vəziyyəti əvəzedici deyil, hər ikisi eyni anda dəyişsə belə. Obyektin kimliyini müşahidə ilə birlikdə saxlayın ki, sonrakı hesabat hansı profilin onu yaratdığını deyə bilsin. Maşının çoxlu vəziyyəti var; bildiriş onlardan biri haqqındadır.

Sonra bildirişin nə demək olduğuna qərar verin. Aktivləşməyə heç vaxt çatmayan bağlantı quraşdırma uğursuzluğudur, aktiv olub sonra yoxa çıxan sessiya isə itkidir. Bunlar fərqli sözlərə layiqdir.

Hansı keçidi bildirdiyinizi deyin

Yeni dəyəri təcriddə yoxlamaq əvəzinə əvvəlki vəziyyəti saxlayın və onu yenisi ilə müqayisə edin. Uğursuz vəziyyətə keçid və aktiv vəziyyətdən çıxış fərqli hadisələrdir, hər ikisi heç nə bağlı olmadan bitsə belə. Səbəb sətrini yanında qeyd edin, çünki çox vaxt istifadəçinin üzərində hərəkət edə biləcəyi yeganə hissə odur.

Qəsdən bağlantının kəsilməsi nasazlıq deyil. Bildiriş fərqi ayırd edə bilmirsə, insanları ona məhəl qoymamağa öyrədəcək.

Müşahidəçini canlı saxlayın

Təkrar sorğulama dəyişməmiş vəziyyət üçün başqa xəbərdarlıq yaratmamalıdır. Bu tək qayda bu bildirişçilərin yaratdığı səs-küyün çoxunu aradan qaldırır.

Menecerin yenidən başlaması və ya müşahidə olunan obyektin dəyişdirilməsi halını da nəzərə alın. Köhnəlmiş kimliyə bağlanmış izləyici maraqlı bir şeyin baş verdiyi anda susur və sükut sağlamlıq kimi görünür. Menecerin mövcudluğu dəyişdikdən sonra cari obyekti yenidən kəşf edin və yenidən kəşfin nə vaxt baş verdiyini qeyd edin. Əks halda jurnal sadəcə hesabat verməyi dayandıran bir tunel göstərir.

Bildirişi istifadəçinin olduğu yerə çatdırın

İmtiyazlı sistem geri çağırışı masaüstü sessiyasının bildiriş xidmətini miras almır. Kök səviyyəli emalçıdan göndərilən mesaj xəta vermədən yox ola bilər, bu da əl ilə sınaqdan keçirildikdə işləyən və praktikada heç vaxt işləməyən bir bildirişçi yaradır. Masaüstünə sahib olan sessiyaya çatdırın və ya masaüstünün öz müştərisi bildirişi qaldırsın.

Əgər müştərinin mövcud bildirişi artıq bu halı əhatə edirsə, ona üstünlük verin, çünki bir hadisə üçün iki bildirişçi artıqlıq deyil, dəstək problemidir. Hadisə vaxtını, profili və səbəbi dəstək qeydində saxlayın, parolları və tam profilləri oradan kənarda saxlayın. Bildirişin nə olduğunu unutmayın: müşahidə olunan vəziyyətin hesabatı, tətbiq mexanizmi deyil, çünki tunel olmadıqda trafiki bloklamaq öz icrası olan ayrı siyasətdir.