Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Monitorowanie portów TCP/UDP


Matix8981
 Udostępnij

Rekomendowane odpowiedzi

Właśnie aktualnie nie posiadam żadnego monitoringu, Posiadam serwer pewnej gry który posiada protokół główny UDP. Można sprawdzić czy serwer działa poprzez lib GameQ w php lecz nie zawszę poprawnie skomunikuje się z PHP. Również poszukuje monitoringu do innych rzeczy na portach TCP/UDP, lecz głównie pod serwer gry bo czasem lubi się zcrashować :)

Odnośnik do komentarza
Udostępnij na innych stronach

3 minuty temu, SomeGuy napisał:

Jeśli stoi na linux to trochę od d strony, wystarczy sprawdzić czy aplikacja chodzi/jaki kod wyjścia przy ew. error. GameQ z tego co widzę po prostu wysyła zapytanie do serwera, zrób to samo z pominięciem PHPa. 

Oczywiście że linux, nie pchał bym się nigdy na Windows'a. W tym jest problem, że proces chodzi lecz crash się robi i serwer stoi w stanie hibernacji i muszę go resetować ręcznie. Więc zostaje napisać coś w stylu GameQ na bash zamiast PHP.

Odnośnik do komentarza
Udostępnij na innych stronach

Z grami za wiele wspólnego już nie mam, ale swojego czasu Q3 był całkiem solidnie rozbudowany pod względem remote access, i z serwera zewnętrznego (czy też PCta) można było wysłać zwykłe zapytanie w stylu "get players list" (dawno dosyć i nie pamiętam teraz dokładnie). Jeśli natomiast ta gra jest popularna to na pewno istnieją już rozwiązania na tę bolączkę.  Na przyszłość pytaj wprost, łatwiej nakierować na odpowiedź czy też rozwązanie lub wskazówkę. Monitoring TCP/IP to zbyt obszerne pojęcie. 

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Najlepszą metodą monitoringu będzie query np. w php o którym już wcześniej wspomniałeś. Jeżeli obawiasz się fałszywych wyników to ustaw odpowiednio wyższy timeout a do tego 2-3 krotne powtórzenie komunikacji w przypadku braku odpowiedzi, następnie reakcja w postaci restartu serwera.

 

Inna metoda to analiza logów serwera gry wywoływana z crona. Tworzysz sobie w systemie skrypt w bashu który szuka w logach informacji o crashu serwera. Jeżeli ją znajdzie to wykonuje restart serwera.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

4 godziny temu, Archi napisał:

Nawet mi się nie chce ładnego basha pisać na takie bzdety

 

a potrafisz ładny bash napisać ? ;-)

Należy jednak przyznać że rozwiązanie @Archi choć "toporne" to jedyne rozsądne. @MateuszCODE zakłąda monitorowanie portu tcp/udp, tak jak w przypadku tcp nie ma większego problemu, tak w przypadku udp nie jest to takie banalne :-) Choć jak rozwiązanie przedstawione przez @Archi wskazuje jeśli monitorujemy z tego samego systemu na którym socket jest otwarty to jest to znacznie prostsze.

Natomiast wygląda na to że @MateuszCODE  nie planuje monitorować portu udp, a jedynie usługę która jest udostępniona na tym porcie, a to znacząco upraszcza zadanie :-) Najwygodniej prosty skrypt w pętli wysyłający request po UDP, czekający na odpowiedź, sprawdzający zawartość po czym czekający "n" czasu do kolejnej próby.

 

Jeśli natomiast monitorując z tego samego hosta jak sugeruje @Archi to ja bym bardziej szedł w kierunku:

 

sudo lsof -Pi UDP:53

 

Odnośnik do komentarza
Udostępnij na innych stronach

@MateuszCODE ja bym nie szedł w kierunku monitorowania otwartego socketu, a na bazie tego co pisałeś bardziej w monitorowanie aplikacji przez otwarty socket. Czyli wysłania zapytania do aplikacji przez sieć, otrzymanie odpowiedzi, podjęcie decyzji co dalej zrobić na tej bazie, odczekanie wyznaczonego czasu i ponownie od początku. Jak sam napisałeś w przypadku "crash" process nadal działa i w takiej sytuacji zapewne także socket nadal jest otwarty wiec monitorowanie samego socketu nic Tobie nie wniesie.  

Odnośnik do komentarza
Udostępnij na innych stronach

No jeśli aplikacja jest tak spieprzona, że nawet socketu nie umie zamknąć jak się wywali to rzeczywiście pozostaje Ci wysłanie odpowiednio requesta i czekanie na odpowiedź. W tym wypadku wykorzystanie jakiejś biblioteki API danej gry będzie lepsze niż wysyłanie czystych pakietów po UDP.

Odnośnik do komentarza
Udostępnij na innych stronach

17 godzin temu, Archi napisał:

No jeśli aplikacja jest tak spieprzona, że nawet socketu nie umie zamknąć jak się wywali

 

Wszystko zależy od architektury aplikacji, jeśli składa się z licznych komponentów w formie subsystemów, mikroserwisów lub podobnych to część odpowiedzialna za otwarty socket jest tylko gatewayem, zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket. Dobrym przykładem jest serwer http (np. apache lub nginx) i serwer aplikacji php działający osobno (w formie fpm lub podobnej). Błąd aplikacji lub serwera aplikacyjnego nie oznacza w takim przypadku konieczności zwolnienia socketu.

Jednak coś czuję że to jest jednak aplikacja monolityczna :-)

Odnośnik do komentarza
Udostępnij na innych stronach

14 godzin temu, gb1 napisał:

zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket.

 

Jeśli następuje crash aplikacji, w której nie jest ona w stanie poprawnie dalej funkcjonować (a nie jakiś wyjątek pojedynczego requesta), to aplikacyjnym obowiązkiem jest zwolnić wszelkie zasoby, w tym sockety, wątki jak i swoje podprocesy, a następnie zakończyć się z nie-zerowym kodem błędu. Taka sytuacja jest jedynie dopuszczalna w trybie debugowania gdy aplikacja czeka na podpięcie debuggera typu GDB w celu zbadania problemu.

 

Oddziel sobie terminy "błąd aplikacji" od "crash aplikacji". Błąd to sytuacja obsłużona, w której coś co nie powinno się wydarzyć się wydarzyło - nieistotne jest to co tym błędem jest, jeśli aplikacja ma logikę żeby go obsłużyć (niezależnie czy to będzie shutdown, continue, exception czy wpis do logu), to jest w stanie dalej działać (a jak nie to ponownie kończy się z nie-zerowym kodem błędu i zwalnia zasoby). Crash to sytuacja w której aplikacja nie ma logiki do obsługi danego zdarzenia, może to być zarówno native crash jak np. segfault, ale i managed crash jak np. NRE w językach obiektowych czy po prostu stack overflow albo inne przypadki. W takiej sytuacji proces aplikacji ma obowiązek się zakończyć z nie-zerowym kodem błędu, tak aby kernel mógł zwolnić zasoby. W przypadku np. takiego segfaulta, to się dzieje automatycznie i już nie masz pola do manerwu bo kernel robi to za ciebie.

 

Nie ma tutaj pola do dyskusji - jeśli taka aplikacja "zwisa" w miejscu i czeka na killa to jest spieprzona, chyba że działa w trybie debugowania, a takie tryby nie są rozwiązaniami produkcyjnymi.

Odnośnik do komentarza
Udostępnij na innych stronach

@Archi zgadzam się z Tobą jednak bierzesz pod uwagę monolityczne aplikacje, trudno aby bardziej złożone aplikacje o architekturze rozproszonej się w taki sposób zachowywały :)

 

9 godzin temu, Archi napisał:

jeśli taka aplikacja "zwisa" w miejscu i czeka na killa to jest spieprzona, chyba że działa w trybie debugowania, a takie tryby nie są rozwiązaniami produkcyjnymi.

 

Tak powinno być, jednak życie pokazuje że teoria znacznie różni się od praktyki :-)

Odnośnik do komentarza
Udostępnij na innych stronach

To czy aplikacja jest monolityczna czy rozproszona nie ma dużo do gadania. Nie oczekuję od slave'a mysql, że zabije mi mastera, bo to jest niedorzeczne, ale jak najbardziej powinien zakończyć proces z nie-zerowym kodem błędu jeśli dojdzie do jakiegoś nieobsłużonego błędu czy crasha. Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

Odnośnik do komentarza
Udostępnij na innych stronach

16 godzin temu, Archi napisał:

Obowiązkiem procesu w przypadku awarii jest zakończyć wszystkie swoje procesy i procesy dzieci, nie musi od razu rozwalać całej architektury, to tak jak padnięcie pojedynczego node'a.

 

Czyli jednak gra rolę czy aplikacja jest monolityczna czy rozproszona :-) Z powyższym się jak najbardziej zgadzam, jednak zaprzecza to Twojemu pierwszemu zdaniu. Jeśli jeden "node" w aplikacji się "crashuje" nie oznacza że socket na którym przyszło zapytanie musi zostać zwolniony, zatem monitorowanie tego socketu nie jest zbytnio istotne. Pamiętajmy jakiego konkretnego przypadku dyskusja dotyczy. 

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
 Udostępnij

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.