Wykrywanie zerwanego połączenia

Wszelkie pomysły dotyczące Arkadii.
Pulp
Posty: 274
Rejestracja: 21 maja 2009 00:44

Wykrywanie zerwanego połączenia

Post autor: Pulp »

Problem 1: Kiedy gracz straci połączenie w wyniku jakiejś awarii, mud przeważnie tego nie wykrywa i postać zostaje w świecie 5-30 minut, w zależności od wybranej opcji. Taka niekontrolowana postać narażona jest na zupełnie bezsensowne zgony, których niemal na pewno uniknęłaby, gdyby gracz połączenia nie stracił. Kara za zgon jest na arce bardzo dotkliwa i otrzymanie jej z powodu padu łącza jest bezzasadne i niesamowicie szkodliwe dla tzw. "user experience".

Problem 2: Połączenie z Arkadią często staje się nieaktywne (gdy na coś czekamy a na lokacji nic się nie dzieje). Routery mają tablice połączeń o ograniczonym rozmiarze, więc muszą co jakiś czas zwalniać w niej miejsce, usuwając stare/nieaktywne połączenia. Z moich doświadczeń wynika, że połączenie z arką może zostać usunięte przez nieaktywność już po 20 sekundach, co jest bardzo irytujące. Zależy to od jakości routera oraz jego obciążenia. Z kilkoma routerami miałem ten problem, z innymi zdawał się on nie występować.


Rozwiązanie: opcje ping +/-
Gdy włączona, serwer co 5 sekund lub po 5 sek. nieaktywności wysyła trzy następujące bajty: ff fb a0, jeżeli w ciągu 5 sekund klient nic nie wyśle do serwera, serwer czeka aż postać ochłonie od walki (jeżeli to konieczne) a następnie zrywa połączenie (nie wylogowuje).

Każdy klient zgodny z protokołem telnet, na ff fb a0 ("chciałbym włączyć niestandardową opcję a0, yo!") odpowie ff fe a0 ("odwal sie, nie znam niestandardowej opcji a0, yo!") testowałem na zMudzie, putty i windowsowym telnecie. Każdy szanujący się klient mudowy powinien reagować tak samo, gdyby ktoś jednak korzystał z nieszanującego się klienta lub lagi na poziomie 5 sekund to u niego norma, może po prostu tej opcji nie włączyć.
Dhogrin
Posty: 167
Rejestracja: 16 lut 2009 00:34
Lokalizacja: Konin / Poznań

Re: Wykrywanie zerwanego połączenia

Post autor: Dhogrin »

Jako ten, któremu w niesprzyjających okolicznościach zdarza się być ofiarą problemu zarówno pierwszego jak i drugiego, podpisuje się wszystkimi rączkami pod tym co Pulp napisał. :)
Aphazel
Posty: 148
Rejestracja: 13 maja 2009 09:44

Re: Wykrywanie zerwanego połączenia

Post autor: Aphazel »

Jeśli już korzystamy ze standardu protokołu TELNET, to nie należy na pałę dodawać nowych wartości. Co będzie, jeśli zmieni się specyfikacja protokołu, ta wartość zostanie zajęta, a klienty zaktualizowane do nowej specyfikacji?

Ponadto polecam przyjrzeć się istniejącej już specyfikacji: http://www.rfc-editor.org/rfc/rfc854.txt Na stronie 14 zestawione są wartości liczbowe dla poszczególnych kodów. I jest tam coś takiego, jak AYT (are you there), co zdaje się zostało utworze z myślą o takiej właśnie funkcjonalności, jak wspominasz Pulpie.

Dodam, że warto by zaimplementować to w obie strony - jeśli klient zapytuje AYT - serwer też powinien odpowiedzieć. Może już coś takiego śmiga, sprawdzał ktoś? Natomiast względem wysyłania do klienta zapytania, to stałe co 5 sek IMO zbędne. Skoro jest mechanizm do sprawdzania nieaktywności, to wpleść do niego wysyłanie AYT po X sekundach nieaktywności (czyli druga wersja proponowana przez Pulpa jest wg mnie rozsądniejsza). Do tego wszystkiego należy pamiętać o zaimplementowaniu zgodnie z RFC opcji WILL/WON'T/DO/DON'T.
Pulp
Posty: 274
Rejestracja: 21 maja 2009 00:44

Re: Wykrywanie zerwanego połączenia

Post autor: Pulp »

Nie masz pojęcia o czym piszesz, Aphazel.
Awatar użytkownika
Werbat
Posty: 1357
Rejestracja: 12 lut 2009 21:25
Lokalizacja: Poznań
Kontakt:

Re: Wykrywanie zerwanego połączenia

Post autor: Werbat »

1) było już dyskutowane - trochę ciężko, żeby mud automagicznie wykrywał 'pad łącza', tego się tak niezbyt da zrobić z okazji specyfikacji TCP/IP jako takiego.

2) to się nazywa keep-state i jak najbardziej da się używać. Nie zależy tak bardzo od 'routera', jak chce Pulp, co raczej od operatora. W putty odpowiednie okienka są w zakładce 'Connection', zMud/CMud nie mają takiej opcji same w sobie (szukałem niedawno dla kogoś z 'problemem rozłączającej się od nieaktywności arki', na ichnich forach temat pojawia się kilkukrotnie jako feature request, póki co bez odzewu ze stony developerów). Można to jednakże włączyć na poziomie systemu operacyjnego - w Windows XP oraz Windows 7 edytując odpowiednie wpisy w rejestrze (UWAGA: zdarzyło mi się, że u osoby X pomogło, a u osoby Y nie - nie wiem, czemu, nie miałem czasu oraz wystarczającej wiedzy o Windows, żeby zdiagnozować); w Mac OS X to dwa wpisy w sysctl.conf (sam korzystam, mój operator ucina nieaktywne sockety); w Linuksie/BSD nie próbowałem, ale na 98% identycznie jak w OSX.

ps.
@Aphazel wie, że gdzieś dzwonią, ale nie do końca ogarnia, gdzie ;-) Rozśmieszyła mnie obawa 'a co się stanie, jak zmieni się specyfikacja protokołu telnet', a potem powoływanie się na RFC, które właśnie jednoznacznie takie specyfikacje opisuje.
I aim to misbehave.
Systematycznie dążę do wyrugowania hejtu z arsenału swoich środków wyrazu.
Pulp
Posty: 274
Rejestracja: 21 maja 2009 00:44

Re: Wykrywanie zerwanego połączenia

Post autor: Pulp »

Werbat:
1) Da się to zrobić i właśnie napisałem jak. To że w poprzedniej dyskusji nikomu sie nie chciało zajrzeć do specyfikacji i zaproponować sensownego, konkretnego rozwiązania nie jest powodem by problem zignorować na wieki.

2) Mieszasz tu kilka spraw. Problem zależy od routerów, te zaś mogą należeć do operatora lub odbiorcy. W moim przypadku, zmiany routerów, które oberwały piorunem, powodowały pojawianie się bądź znikanie tego problemu. Operator ciągle ten sam.

Mechanizm, o którym piszesz nazywa się keepalive (?) i jest to mechanizm pingopodobny na poziomie protokołu TCP. Ze względu na charakter TCP, domyślny interwał wysyłania pakietów keepalive wynosi bodajże 2 godziny, ponieważ służy on raczej do sprzątania starych socketów, natomiast ping do szybkiego wykrywania zerwanych połączeń implementuje się w protokołach warstw wyższych.

Zmiana parametrów TCP keepalive z 2godzin do powiedzmy 10 sekund również rozwiązuje oba problemy, jednak może być niewskazana jeśli na serwerze działają jeszcze jakieś inne usługi sieciowe prócz muda. Ponadto nie jestem pewien, czy aplikacja może manipulować tymi parametrami niezależnie od systemu operacyjnego. Wiesz może?
Awatar użytkownika
Werbat
Posty: 1357
Rejestracja: 12 lut 2009 21:25
Lokalizacja: Poznań
Kontakt:

Re: Wykrywanie zerwanego połączenia

Post autor: Werbat »

Oczywiście, że keepalive, przepraszam za to keep-state, pisałem na szybko i mi się z firewallami pomyliło ;-)

Aplikacja może wysyłać pakiety keepalive niezależnie od ustawienia systemu - przykładem niech będzie chociażby putty. Problem właśnie z tym, żeby klienty muda miały to ziamplementowane - bez tego trzeba 'zmusić' cały system.

Natomiast nie jestem pewien, gdzie jest to Twoje 'niewskazanie'. Keepalive działa per połączenie, przez co nie widzę powodu, dlaczego wysyłanie pakietu kontrolnego _wewnątrz_ już nawiązanej sesji (w tym przypadku - połączenia z mudem) niekoniecznie miałoby wpływać na wydajność 'innych uslug sieciowych'.


No i zupełnie nie rozwiązuje to problemu 1). W momencie, kiedy pada Ci łącze przestajesz też wysyłać pakiety keepalive ;-) Na wykrywanie tego mogłoby pomóc wyłącznie coś przychodzącego ze strony muda.
I aim to misbehave.
Systematycznie dążę do wyrugowania hejtu z arsenału swoich środków wyrazu.
Pulp
Posty: 274
Rejestracja: 21 maja 2009 00:44

Re: Wykrywanie zerwanego połączenia

Post autor: Pulp »

Chodziło mi o to, że niewskazana może być zmiana globalnych parametrów systemu. Niektóre połączenia mogą zostać przerwane a następnie wznowione, jakby nic się nie stało. Ale jeśli zmiany w systemie nie są konieczne to nie ma problemu.

Co do problemu 1, przecież chodzi mi o to, żeby to serwer wysyłał pakiet keepalive i nie otrzymawszy odpowiedzi, zrywał połączenie.

Nie sprawdzałem, czy klienty mudowe odbijają keepalive (powinny), 3 które sprawdziłem na pewno odbijają zaproponowany przeze mnie "ping" na poziomie telnetu.

ps.
Wybrałem wersje telnetową, bo wydaje mi się, że komende telnetu można bezproblemowo wysłać z poziomu LPC, co chyba ułatwi integrację z mudowymi "opcjami". Z manipulowaniem flagami TCP na tym poziomie może być problem. Bez ingerencji w driver prawdopodobnie i tak sie nie obejdzie, jednak chyba warto ograniczyć ją do minimum.
Aphazel
Posty: 148
Rejestracja: 13 maja 2009 09:44

Re: Wykrywanie zerwanego połączenia

Post autor: Aphazel »

Pulp pisze:Nie masz pojęcia o czym piszesz, Aphazel.
Rozmówcy, jak widzę, są za to świetnie obeznani z tematem.
Werbat pisze:Rozśmieszyła mnie obawa 'a co się stanie, jak zmieni się specyfikacja protokołu telnet', a potem powoływanie się na RFC, które właśnie jednoznacznie takie specyfikacje opisuje.
Zmiana, to także rozszerzenie, tutaj jest przykład: http://www.faqs.org/rfcs/rfc729.html

Co będzie, jeśli jacyś mistrzowie wydumają kolejną rzecz po MCCP, MXP i innych, która będzie używać kodu A0 (dla wygody nazwijmy tę komendę LIPA, a protokół MLP - Mudowy Lipny Protokół) i do tego (nie daj bloże) w sposób blokujący? Pulp proponuje, żeby serwer wysyłał IAC WILL LIPA a następnie zadowalał się jakąkolwiek odpowiedzią i na jej podstawie działał zawsze w ten sam sposób. Nie ma problemu, jeśli dotychczas działające klienty będą odsyłać IAC DON'T LIPA. Teoretycznie można działać, choć nie będzie to zgodne z RFC 854/855 (bo to przecież odrzucenie w negocjacji). A co się stanie, jeśli klient wyśle IAC DO LIPA, bo w kolejnych wersjach klientów zostanie zaimplemetowany MLP? Przypominam, że implementacja MLP zakłada oczekiwanie na odpowiedź w sposób blokujący. No i właśnie. Będzie lipa. Inny przykład to taki, że MLP nie jest blokujący, ale nie czeka na IAC SB/SE tylko ciągnie kolejne dane jak leci i interpretuje. Również lipa.

Moglibyście zapytać, kto normalny może wydumać taki zje**ny MLP? No to popatrzcie sobie na MCCP i MXP, które wymieniłem. Tutaj http://www.zuggsoft.com/page.php?file=zmud/mcp.htm w temacie o MCCP można dostrzec m.in. "note that this is not a valid suboption negotiation sequence according to RFC854/855 -- the terminating SE isn't correctly escaped". A tutaj http://www.gammon.com.au/forum/bbshowpo ... ect_id=305 względem MXP również problemy.

Dlatego uważam, że najrozsądniejsze wyjście, to implementsacja AYT zgodnie ze standardem i sprawdzenie, jak klienty reagują na AYT. Jeśli nijak lub odrzucają, niezbędna jest implementacja właściwej reakcji na AYT w klientach, co w praktyce na daną chwilę prowadzi nas do nikąd.

PS. Już nie chce mi się podawać linków uzasadniających, dlaczego o aplikacjach klienckich piszę "klienty", a nie "klienci". Napisz jeszcze raz, Plup, że nie mam pojęcia, o czym piszę. Choć w tym przypadku to może raczej działka Werbata.
Pulp
Posty: 274
Rejestracja: 21 maja 2009 00:44

Re: Wykrywanie zerwanego połączenia

Post autor: Pulp »

Aphazel pisze:
Werbat pisze:Rozśmieszyła mnie obawa 'a co się stanie, jak zmieni się specyfikacja protokołu telnet', a potem powoływanie się na RFC, które właśnie jednoznacznie takie specyfikacje opisuje.
Zmiana, to także rozszerzenie, tutaj jest przykład: http://www.faqs.org/rfcs/rfc729.html
Rozszerzenie z 1977 roku? Mistrz ciętej riposty normalnie.
Co będzie, jeśli jacyś mistrzowie wydumają kolejną rzecz po MCCP, MXP i innych, która będzie używać kodu A0 (dla wygody nazwijmy tę komendę LIPA, a protokół MLP - Mudowy Lipny Protokół) i do tego (nie daj bloże) w sposób blokujący? Pulp proponuje, żeby serwer wysyłał IAC WILL LIPA a następnie zadowalał się jakąkolwiek odpowiedzią i na jej podstawie działał zawsze w ten sam sposób.
Jeżeli powstanie konflikt z jakimś nowym protokołem, który się przyjmie i zostanie zaimplementowany w klientach, co jest bardzo mało prawdopodobne, to wpiszesz sobie "opcje ping -" w swym awangardowym kliencie i zaczekasz aż administracja zmieni wartość a0 na dowolną inną, która nie będzie powodować konfliktu.
Nie ma problemu, jeśli dotychczas działające klienty będą odsyłać IAC DON'T LIPA. Teoretycznie można działać, choć nie będzie to zgodne z RFC 854/855 (bo to przecież odrzucenie w negocjacji).
Przytocz proszę fragment rfc, z którym odsyłanie IAC DON'T LIPA jest niezgodne.
Dlatego uważam, że najrozsądniejsze wyjście, to implementsacja AYT zgodnie ze standardem i sprawdzenie, jak klienty reagują na AYT. Jeśli nijak lub odrzucają, niezbędna jest implementacja właściwej reakcji na AYT w klientach, co w praktyce na daną chwilę prowadzi nas do nikąd.
Klienty nie odpowiadają na AYT, bo ta funkcja służy do czegoś innego, o czym byś wiedział, gdybyś przeczytał ze zrozumieniem rfc, do których nas odsyłasz. Skończ już z łaski swojej pieprzyć dla samego pieprzenia i siać defetyzm.
ODPOWIEDZ