Pod maską
Jak działa myNetWorking
Co dzieje się pod maską: jedno sprawdzenie, odróżnianie awarii usługi od kłopotów z Twoim łączem, praca w tle, dane i wydania.
Jedno sprawdzenie
myNetWorking nawiązuje połączenie TCP z hostem i portem usługi. Jeśli port przyjmie połączenie, usługa działa — aplikacja od razu je zamyka i nie wysyła żadnych danych. Nie jest to ping ani zapytanie HTTP, tylko samo nawiązanie połączenia.
Czas odpowiedzi to czas od rozpoczęcia łączenia do sukcesu. Dla nazw hostów obejmuje też wyszukanie nazwy w DNS.
Limit czasu połączenia wynosi domyślnie 5 sekund. Możesz go zmienić w zakresie od 1 do 60 sekund.
Kiedy sprawdzenie? Od razu po uruchomieniu aplikacji oraz po dodaniu, edycji i ponownym włączeniu usługi. Potem po upływie Częstotliwości sprawdzania usługi (domyślnie 30 sekund), a po nieudanym sprawdzeniu — po upływie Częstotliwości sprawdzania podczas awarii z ustawień (domyślnie 10 sekund).
Odstęp liczy się od końca poprzedniego sprawdzenia. Ta sama usługa nigdy nie jest sprawdzana dwa razy jednocześnie. Przez cały czas sprawdzania, razem z weryfikacją, usługa ma status „Sprawdzanie…”.
Weryfikacja awarii krok po kroku
Gdy połączenie się nie uda, aplikacja nie ogłasza od razu awarii. Przechodzi przez następujące kroki:
Łączy się z usługą. Sukces oznacza status „Działa”.
Po nieudanej próbie pyta o stan łącza. Jeśli łącze nie jest w pełni sprawne, usługa dostaje status „Brak sieci”.
Jeśli łącze działa, łączy się z usługą drugi raz, od razu. Sukces oznacza „Działa”.
Po drugiej nieudanej próbie sprawdza łącze jeszcze raz, od nowa. Jeśli nie jest w pełni sprawne albo w ciągu ostatnich 30 sekund były z nim kłopoty, usługa dostaje status „Brak sieci”.
Jeśli za drugim razem nie udało się rozwiązać nazwy hosta, a ta sama nazwa rozwiązywała się wcześniej, winny jest DNS — status „Brak sieci”.
W każdym innym przypadku usługa dostaje status „AWARIA”.
Tylko „AWARIA” otwiera incydent i uruchamia alarm. „Brak sieci” oznacza problem po Twojej stronie: aplikacja zapisuje go w logu, ale nie obwinia usługi.
Serwery odniesienia i kworum
Stan łącza aplikacja ocenia, łącząc się równolegle z serwerami odniesienia — domyślnie z portem 53 serwerów 1.1.1.1, 8.8.8.8 i 9.9.9.9. To takie samo nawiązanie połączenia TCP jak przy usługach, z tym samym limitem czasu. Aplikacja nie wysyła do nich zapytań DNS.
Serwer odniesienia jest zaufany, gdy choć raz odpowiedział od uruchomienia aplikacji (liczy się także bieżąca próba). Wynik oceny zależy od zaufanych serwerów:
| Wynik | Kiedy | Co to znaczy dla usług |
|---|---|---|
| łącze działa | odpowiedziały wszystkie zaufane serwery | usługa, która nie odpowiada, może dostać status „AWARIA” |
| łącze niestabilne | część zaufanych serwerów odpowiedziała, a część nie | „Brak sieci” — żadna usługa nie jest obwiniana |
| brak łącza | nie odpowiedział żaden zaufany serwer | „Brak sieci” |
Kilka dodatkowych zasad:
Brak połączenia sieciowego — tryb samolotowy albo odłączony kabel — aplikacja rozpoznaje od razu, bez czekania na limity czasu.
Wspólna ocena. Wszystkie usługi korzystają z tej samej oceny, ważnej przez 3 sekundy. Dwie usługi, które przestały odpowiadać w tej samej sekundzie, nie mogą więc dostać sprzecznych wyników.
30 sekund ochrony. Każda ocena „niestabilne” albo „brak łącza” uruchamia 30-sekundowy okres, w którym niedziałające usługi dostają status „Brak sieci”, a nie „AWARIA”.
Wynik „niestabilne” jest możliwy dopiero wtedy, gdy przestanie odpowiadać serwer, który wcześniej odpowiadał. Pierwsza ocena po uruchomieniu wypada więc „łącze działa”, gdy odpowie choć jeden serwer.
Przykład: niestabilne Wi-Fi i prawdziwa awaria
Przykład z ustawieniami domyślnymi: NAS pod adresem 192.168.1.50:445 sprawdzany co 30 sekund, podczas awarii co 10 sekund, limit czasu 5 sekund. Od uruchomienia aplikacji wszystkie trzy serwery odniesienia już choć raz odpowiedziały (np. przy wcześniejszym nieudanym sprawdzeniu), więc wszystkie są zaufane.
| Godzina | Co się dzieje | Wynik |
|---|---|---|
| 10:00:00 | NAS odpowiada w 4 ms | „Działa” |
| 10:00:30 | Wi-Fi gubi pakiety, NAS nie odpowiada. Serwery 1.1.1.1 i 9.9.9.9 odpowiadają, 8.8.8.8 — nie | łącze niestabilne: „Brak sieci”, wpis w logu, bez incydentu i alarmu |
| 10:00:50 | NAS nadal milczy. Serwery odpowiadają już wszystkie, ale od kłopotów z łączem nie minęło 30 sekund | nadal „Brak sieci” |
| 10:01:10 | Wi-Fi wróciło do normy, NAS odpowiada | „Działa” |
| 10:30:00 | Ktoś wyłącza udostępnianie plików na NAS-ie: port 445 od razu odrzuca połączenie. Druga próba też się nie udaje, a wszystkie serwery odniesienia odpowiadają przed nią i po niej | „AWARIA”: incydent, wpis w logu, powiadomienie z dźwiękiem i alarm powtarzany co 60 sekund |
| 10:30:10 i dalej | NAS jest sprawdzany co 10 sekund | nadal „AWARIA” |
| 10:42:10 | Udostępnianie znów działa, NAS odpowiada | „Działa”: incydent zamknięty z czasem trwania 12m 10s, wpis w logu i powiadomienie o przywróceniu |
W wersji 1.0.0 o 10:00:30 wystarczyłaby odpowiedź jednego serwera odniesienia, żeby uznać łącze za sprawne — NAS dostałby wtedy fałszywą „AWARIĘ”.
Jak szybko widać awarię
Połączenie odrzucone (host działa, ale usługa na porcie jest wyłączona) aplikacja wykrywa niemal natychmiast — „AWARIA” pojawia się w tym samym sprawdzeniu.
Host, który w ogóle nie odpowiada, może zająć w jednym sprawdzeniu około czterech limitów czasu, czyli do mniej więcej 20 sekund: pierwsza próba, ocena łącza, druga próba i druga ocena.
Najgorszy przypadek od początku awarii do statusu „AWARIA” to więc częstotliwość sprawdzania plus około 20 sekund — przy ustawieniach domyślnych mniej więcej 50 sekund.
W ciągu 30 sekund od kłopotów z łączem prawdziwa awaria zostanie zgłoszona przy pierwszym sprawdzeniu po upływie tego czasu.
Kontrola samego internetu
Niezależnie od usług aplikacja może pilnować samego połączenia z internetem. Włączasz to w Ustawienia → Połączenie z internetem: jeden przełącznik daje osobne powiadomienie i wpis w logu, drugi zapisuje każdą przerwę jako incydent. Gdy któryś jest włączony, łącze jest sprawdzane co 30 sekund, a podczas przerwy co 10 sekund. Wynik „niestabilne” nie jest ani przerwą, ani powrotem. Szczegóły opisuje rozdział Kontrola internetu.
Praca w tle
Monitorowanie działa na Twoim urządzeniu, bez serwera w chmurze. Gdy aplikacja jest zamknięta albo urządzenie wyłączone, nic nie jest sprawdzane.
macOS, Windows, Linux: aplikacja monitoruje, dopóki działa. Zamknięcie okna na macOS i Windows chowa je do paska menu lub zasobnika systemowego, a na Linuksie minimalizuje. Monitorowanie kończy dopiero polecenie Zakończ.
Android: monitorowanie utrzymuje usługa pierwszoplanowa ze stałym powiadomieniem „myNetWorking monitoruje”. Od wersji 1.1.0 jest to usługa typu specjalnego przeznaczenia (
specialUse), której nie dotyczy 6-godzinny dobowy limit, jaki Android 15 nakłada na usługi synchronizacji danych. Działa, dopóki choć jedna usługa ma włączone monitorowanie. Po ponownym uruchomieniu telefonu trzeba raz otworzyć aplikację.iPhone i iPad: pełne monitorowanie działa tylko przy otwartej aplikacji, bo iOS zatrzymuje w tle jej zegary. Aplikacja zgłasza systemowi zadanie odświeżania w tle nie częściej niż co 15 minut, ale to iOS decyduje, czy i kiedy je uruchomi. W takiej rundzie każda włączona usługa jest sprawdzana raz, z pełną weryfikacją, a zmiany trafiają do incydentów, logu i powiadomień.
Więcej w rozdziale Praca w tle.
Gdzie są dane
Lista usług, ustawienia, incydenty, log i ostatnie statusy są zapisywane jako dane JSON w magazynie ustawień systemu — tylko na Twoim urządzeniu. Aplikacja przechowuje do 300 incydentów i 500 wpisów w logu; najstarsze są usuwane automatycznie. Nie ma kont ani synchronizacji, a sama aplikacja nie robi kopii w chmurze — dane mogą się znaleźć jedynie w kopii zapasowej urządzenia, jeśli jest ona włączona w systemie. Dokładne ścieżki znajdziesz na stronie Instalacja.
Prywatność w projekcie
To pełna lista połączeń, które nawiązuje aplikacja:
Próby połączenia TCP z każdą włączoną usługą, zamykane od razu, bez przesyłania danych.
Wyszukiwanie nazw hostów Twoich usług w DNS — przez system operacyjny.
Próby połączenia TCP z serwerami odniesienia — tylko gdy sprawdzenie usługi się nie uda albo cyklicznie, gdy włączona jest kontrola internetu: co 30 sekund, a podczas przerwy w dostępie do internetu co 10 sekund (domyślna wartość ustawienia Częstotliwość sprawdzania podczas awarii).
Tylko w wersjach pobranych z nci.pl i tylko po kliknięciu Sprawdź aktualizacje: jedno zapytanie HTTPS o plik z numerem najnowszej wersji.
Aplikacja nie ma analityki, telemetrii, raportów o awariach ani reklam. Powiadomienia powstają lokalnie. Pamiętaj tylko, że operatorzy monitorowanych hostów i serwerów odniesienia widzą próby połączenia z Twojego adresu IP — jak przy każdym połączeniu.
Jak powstają wydania
Wszystkie wersje powstają z jednego kodu źródłowego (Flutter).
Sklepy: wersje z Mac App Store, App Store, Microsoft Store i Google Play przechodzą weryfikację sklepu, który podpisuje je swoim certyfikatem, dystrybuuje i aktualizuje.
macOS, plik .dmg: aplikacja jest podpisana certyfikatem Developer ID, działa w piaskownicy systemu i jest notaryzowana przez Apple. Gatekeeper rozpoznaje ją więc jako sprawdzoną i pyta tylko, czy otworzyć aplikację pobraną z internetu.
Linux: paczki
.debi.rpmdla x64 i ARM64 buduje automatycznie usługa ciągłej integracji. Przed wydaniem są instalowane na czystych systemach i uruchamiane testowo.Obok plików do pobrania publikujemy sumy kontrolne SHA-256.
Wersje z tej strony różnią się od sklepowych tylko przyciskiem Sprawdź aktualizacje i opisującym go punktem w informacji o prywatności.