Jeśli od jakiegoś czasu bawisz się tekstowymi grami MUD i klientami Telnet na swoim urządzeniu mobilnym , prawdopodobnie napotkałeś ten sam problem: wszyscy mówią o historii Telnetu, nostalgii i anegdotach… ale prawie nikt nie wyjaśnia, jak właściwie komunikują się klient i serwer. Ten artykuł ma na celu wypełnienie tej luki: zagłębienie się w protokół, komunikaty, sekwencje sterujące i sposób, w jaki Twój własny serwer MUD bezproblemowo współpracuje z istniejącymi klientami.
Przyjrzymy się szczegółowo i w przystępny sposób działaniu typowego protokołu MUD opartego na Telnecie , rozszerzeniom używanym w branży (GMCP, MSSP, kompresji itp.), formatowaniu wiadomości, oczekiwaniom klienta mobilnego oraz informacjom wysyłanym z serwera, aby zapewnić płynne działanie bez konieczności tworzenia protokołu od podstaw. Wszystko to zostanie wyjaśnione w standardowym języku hiszpańskim (z Hiszpanii), z jasnymi przykładami i bez zbędnego żargonu.
1. Telnet jako baza: to, czego faktycznie używa większość MUD-ów
Większość klasycznych MUD-ów nie tworzy nowego transportu: opierają się na Telnecie jako warstwie komunikacyjnej między klientem a serwerem . Oznacza to, że ostatecznie wysyłane są strumienie bajtów przez TCP, gdzie zwykły tekst miesza się ze specjalnymi poleceniami Telnetu poprzedzonymi bajtem 255 (0xFF).
Z punktu widzenia sieci serwer MUD zachowuje się jak podstawowy serwer Telnet z wieloma opcjonalnymi rozszerzeniami . Klient (niezależnie od tego, czy jest to urządzenie mobilne, komputer stacjonarny, czy prosty system Telnet) nawiązuje połączenie TCP z portem MUD (często 23, 4000, 5000 itd.), a następnie rozpoczyna się krótka wymiana opcji.
Podczas tych początkowych negocjacji obie strony wysyłają sobie nawzajem sekwencje sterujące Telnet typu „WILL”, „WONT”, „DO” i „DONT”, aby aktywować lub dezaktywować funkcje: echo, rozmiar okna, dodatkowe protokoły, takie jak GMCP, kompresję itp. Wszystkie te dane są przesyłane w formie wymieszanej z tekstem gry, ale klient może je rozróżnić, ponieważ polecenia sterujące są oznaczone dobrze znanym ciągiem 0xFF.
2. Szkielet protokołu Telnet używanego przez MUD-y
W Telnecie każde polecenie sterujące rozpoczyna się bajtem IAC (Interpret As Command, wartość 255) . Po nim następuje jeden lub więcej bajtów wskazujących typ polecenia oraz, w wielu przypadkach, kod opcji. Na standardowym poziomie protokołu MUD można spotkać się przede wszystkim z:
- IAC DO„Chcę, abyś (klient) aktywował tę opcję”.
- IAC NIE„Nie chcę, żebyś korzystał z tej opcji.”
- IAC WILL:„Ja (serwer) mogę i chcę skorzystać z tej opcji.”
- IAC NIE BĘDZIE„Nie skorzystam z tej opcji”.
Opcje są identyfikowane za pomocą numeru; niektóre z nich to stare standardy Telnet, inne to rozszerzenia uzgodnione w społeczności MUD (np. GMCP, MSSP, COMPRESS2 ), które nie pojawiają się w klasycznych dokumentach RFC Telnet, ale stały się de facto „pseudostandardem”, ponieważ są obsługiwane przez głównych klientów.
Jako MUD zazwyczaj inicjujesz dialog, wysyłając sekwencje IAC DO/IAC WILL , aby sprawdzić, co obsługuje klient: czy akceptuje GMCP, czy chce kompresji, czy udostępnia informacje o terminalu itd. Klient odpowie odpowiednio WILL/WONT lub DO/DONT. Twój serwer musi uwzględnić te odpowiedzi i nie używać opcji, jeśli klient jej nie akceptuje.
3. Rozdzielenie tekstu gry i sterowania przez Telnet
Często zadawane jest pytanie, jak odróżnić zwykły tekst gry od poleceń sterujących . Zasada jest prosta: wszystko, co nie jest poprzedzone ciągiem 0xFF, jest uważane za tekst. Polecenia Telnetu zawsze zaczynają się od tego specjalnego bajtu, właśnie po to, aby uniknąć pomyłek.
Przykład koncepcyjny (nie trzeba go kopiować dosłownie, służy jedynie do wizualizacji): serwer może wysłać wiersze opisu środowiska, a następnie sekwencję IAC, aby wynegocjować opcję. Klient odczytuje bajt po bajcie: gdy widzi 0xFF, przechodzi w „tryb poleceń”; przez resztę czasu traktuje to jako tekst, w razie potrzeby stosuje kolor ANSI i wyświetla.
Jeśli kiedykolwiek zajdzie potrzeba wysłania bajtu 0xFF jako części tekstu (dość rzadkie, ale możliwe), należy go „uniknąc” poprzez jego duplikację . Oznacza to, że aby wysłać dosłowny 0xFF w strumieniu danych użytkownika, wysyła się dwa 0xFF jeden po drugim, a klient poprawnie interpretuje je jako „pojedynczy 0xFF tekstu, a nie polecenie”.
4. Format wiadomości tekstowej: linie, podziały i kolory
Większość treści wysyłanych przez MUD składa się z czytelnych wiadomości tekstowych: opisów, okien dialogowych, list obiektów i poleceń . Choć może się to wydawać trywialne, warto zwrócić uwagę na kilka szczegółów, aby upewnić się, że klienci Telnet (zwłaszcza na urządzeniach mobilnych) wyświetlają je poprawnie.
Generalnie, MUD-y nadal używają klasycznego stylu linii zakończonych znakiem CRLF (\r\n) . Niektórzy klienci obsługują tylko znak LF (\n), ale dla maksymalnej kompatybilności zawsze wysyłaj znak powrotu karetki, a następnie znak nowej linii.
Do obsługi kolorów i formatowania, MUD-y zazwyczaj wykorzystują kody ucieczki ANSI osadzone w tekście. Na przykład sekwencje zaczynające się od ESC (0x1B), po których następuje „[31m” dla tekstu czerwonego, „[1m” dla pogrubienia itd. Nie są one częścią samego protokołu Telnet, ale są rozumiane przez większość terminali i zaawansowanych klientów MUD, w tym wielu klientów mobilnych.
5. Rozszerzenia MUD przez Telnet: GMCP, MSSP i firma
Oprócz zwykłego tekstu, wiele współczesnych MUD-ów łączy Telnet z dodatkowymi protokołami, aby wymieniać ustrukturyzowane dane z klientami . Pozwala to klientom mobilnym wyświetlać bogatsze interfejsy niż w przypadku prostego strumienia tekstu.
Do najczęściej spotykanych rozszerzeń zaliczamy:
- GMCP (ogólny protokół komunikacyjny MUD): wysyła informacje w formacie JSON (choć nie zawsze jest to w 100% standard) na temat postaci, mapy, kanałów itp.
- MSSP (protokół stanu serwera Mud): zaprojektowany w celu udostępniania danych serwera (nazwa MUD, liczba graczy, płeć itp.) serwisom oferującym oferty oraz ciekawym klientom.
- KOMPRESUJ / KOMPRESUJ2Kompresja danych w celu zmniejszenia przepustowości, szczególnie przydatna w przypadku wolnych połączeń.
Te rozszerzenia są negocjowane tak samo, jak każda inna opcja Telnetu: serwer zazwyczaj wysyła komunikat IAC WILL GMCP lub IAC DO GMCP i czeka na odpowiedź. Po zaakceptowaniu, rozszerzenie samo definiuje sposób enkapsulacji danych (na przykład GMCP jest negocjowany w ramach podnegocjacji Telnetu: IAC SB <opcja> … IAC SE).
6. Podnegocjacja (SB i SE): kapsułkowanie danych specjalnych
Gdy opcja Telnet wymaga wysłania większej ilości danych niż proste tak/nie, stosowana jest podnegocjacja . Schemat jest następujący:
- IAC SB IAC SE
W tym bloku można wysyłać ciągi znaków, liczby lub określone struktury zdefiniowane przez rozszerzenie . Na przykład GMCP zazwyczaj wysyła coś bardzo podobnego do obiektu JSON, z cudzysłowami, nawiasami klamrowymi i wartościami.
Gdy klient odbiera IAC SB GMCP, wie, że wszystko aż do IAC SE jest częścią pakietu GMCP, a nie standardowego strumienia tekstu gry. Pozwala to na wyraźne oddzielenie danych trafiających do graficznego interfejsu użytkownika od tych trafiających do klasycznego bufora tekstu.
7. Co wysyła serwer MUD: typowy przepływ komunikacji
Wyobraź sobie sekwencję zdarzeń, w której gracz łączy się z mobilnym klientem Telnet do serwera MUD :
- Klient otwiera połączenie TCP do portu MUD.
- Serwer wysyła Ci baner powitalny (tekst) i prawdopodobnie jakieś Sekwencje IAC do handlu opcjami (echo, GMCP, kompresja…).
- Klient odpowiada akceptując lub odrzucając opcje WILL/WONT i DO/DONT.
- Następnie serwer wysyła ekran logowania (tekst) i przetwarza polecenia wpisywane przez gracza.
Serwer musi być zawsze w stanie odczytać dane wejściowe klienta jako połączenie tekstu i poleceń Telnetu , tak jak klient odczytuje dane wyjściowe. Gdy odtwarzacz wpisuje na przykład „północ” i naciska Enter, klient zazwyczaj wysyła ten ciąg znaków, a następnie znaki powrotu karetki i nowej linii. Serwer odczytuje dane do końca linii i interpretuje je jako polecenie od odtwarzacza.
Jeśli klient zdecyduje się na zainicjowanie jakiejkolwiek opcji (na przykład rozpoczęcie negocjacji rozmiaru okna), musisz być przygotowany na otrzymywanie sekwencji IAC od klienta i odpowiednią reakcję, a nie tylko odwrotnie.
8. Co wysyła klient Telnet (w tym klienci mobilni)
Z perspektywy serwera, standardowy klient Telnet (mobilny lub stacjonarny) wysyła zasadniczo dwa rodzaje danych: tekst użytkownika i polecenia Telnet . Tekst jest zazwyczaj w formacie ASCII lub UTF-8, w zależności od klienta; obecnie najlepiej jest założyć co najmniej UTF-8.
Otrzymywane polecenia Telnetu to przede wszystkim odpowiedzi na żądania negocjacji . Jeśli wyślesz `IAC DO GMCP`, klient odpowie `IAC WILL GMCP`, jeśli obsługuje tę funkcję, lub `IAC WONT GMCP`, jeśli nie obsługuje. Może również samodzielnie zainicjować negocjacje (na przykład dotyczące typu terminala).
Ważnym szczegółem dla kompatybilności mobilnej jest to, że wielu współczesnych klientów interpretuje polecenia znak po znaku lub wiersz po wierszu, w zależności od konfiguracji . Wiersz po wierszu jest bardziej powszechny, dlatego należy konstruować analizę składniową poleceń w kategoriach całych wierszy oddzielonych znakiem \r\n, a nie pojedynczych znaków.
9. Korzystanie z serwerów proxy i problemy sieciowe z MUD-ami w sieciach o ograniczonym dostępie
W niektórych środowiskach (np. sieciach korporacyjnych, kampusach lub u niektórych operatorów komórkowych) typowe porty wysokiego poziomu używane przez MUD-y mogą być blokowane przez zapory sieciowe . W takich przypadkach gracze nie mogą połączyć się bezpośrednio z portem MUD-a, mimo że sam Telnet jest dozwolony na standardowych portach.
Klasyczne rozwiązanie polega na użyciu pośredniczącego serwera proxy, który nasłuchuje na dozwolonym porcie (takim jak port Telnet 23 lub port FTP 21) i przekierowuje połączenie do faktycznego portu MUD-a. Serwer proxy działa jak most: klient łączy się z serwerem proxy, a serwer proxy, w tle, otwiera połączenie z serwerem gry.
Często zdarza się również, że kolega ze stałym połączeniem internetowym instaluje proxy na swoim komputerze i zezwala innym graczom na dostęp do MUD-a za pośrednictwem swojego adresu IP . Należy jednak zachować ostrożność w przypadku współdzielonych adresów IP: jeśli wiele kont łączy się z tego samego adresu IP, niektóre MUD-y mogą to uznać za nielegalną rozgrywkę wieloosobową i nałożyć kary. Najlepiej powiadomić administratorów gry, jeśli planujesz regularnie udostępniać swój adres IP.
10. Ograniczenia i ryzyko związane z serwerami proxy dla MUD
Mimo że serwer proxy może okazać się pomocny w przypadku bardzo zamkniętych sieci, obecnie nie ma zbyt wielu niezawodnych publicznych anonimowych serwerów proxy , a te nieliczne, które pozostały, są zazwyczaj przeciążone, niedostępne lub zablokowane ze względów bezpieczeństwa.
Co więcej, te same sieci, które blokują wysokie porty, mogą mieć również zablokowany port 8080 , co jest bardzo powszechne w przypadku serwerów proxy HTTP. Dlatego, jeśli ktoś konfiguruje prywatny serwer proxy do dostępu do MUD-a, zaleca się umieszczenie go na porcie, który prawie nigdy nie jest filtrowany (23, 21 lub innym bardzo powszechnym i dozwolonym porcie w danej sieci).
Nie zapominaj, że te konfiguracje mają wpływ na bezpieczeństwo: ruch przechodzi przez maszynę pośredniczącą, a sesje, hasła itp. mogą być rejestrowane. Z perspektywy projektowania serwera MUD protokół się nie zmienia, ale musisz założyć, że wiele połączeń będzie „opakowywanych” przez serwer proxy , co może skutkować dodatkowymi opóźnieniami lub częstszymi rozłączeniami.
11. Przykład interakcji narracyjnej w obrębie tekstu MUD
Poza aspektami technicznymi, tekstowy MUD opiera się na bogatych opisach i atmosferze . Wiele gier zawiera ikoniczne fragmenty tekstu, cytaty literackie lub niemal poetyckie fragmenty, które serwer przesyła dosłownie do klienta, aby zwiększyć immersję gracza.
Na przykład, gdy postać staje w obliczu kluczowego momentu, na ekranie może pojawić się swego rodzaju „litania przeciwko strachowi” . Technicznie rzecz biorąc, jest to nic więcej niż sekwencja linijek tekstu z odpowiednimi przerwami i, w razie potrzeby, kolorem lub formatowaniem. Jednak z punktu widzenia doświadczenia użytkownika ma to znaczący wpływ.
Ten typ tekstu, choć nie zmienia protokołu Telnet, wpływa na sposób obsługi odstępów między wierszami, paginacji i częstotliwości odświeżania . Wyświetlanie kilku długich akapitów jednocześnie może stać się nieczytelne na małych ekranach (np. w telefonach komórkowych). Dlatego wiele serwerów implementuje systemy „paginacji”, które wstrzymują odtwarzanie po określonej liczbie wierszy i czekają na naciśnięcie klawisza przez odtwarzacz, aby kontynuować.
12. Zasoby zewnętrzne i dodatkowa dokumentacja techniczna
W odróżnieniu od innych wysoce ustandaryzowanych protokołów, ekosystem MUD opiera się na rozproszonych dokumentach, akademickich plikach PDF i luźnych artykułach opisujących warianty, propozycje rozszerzeń i badania dotyczące interakcji w środowiskach MUD.
W repozytoriach uniwersyteckich i bibliotekach cyfrowych dostępne są prace analizujące architekturę klient-serwer w MUD-ach, ewolucję od prostego Telnetu do rozbudowanych protokołów , a nawet kwestie związane z doświadczeniami użytkownika w interfejsach tekstowych. Chociaż wiele z tych dokumentów nie uczy wiersz po wierszu, jak formatować wiadomości, oferują one użyteczny kontekst pozwalający zrozumieć, dlaczego wprowadzono określone protokoły i jak są one łączone.
Aby uzupełnić implementację, wskazane jest również zapoznanie się z dokumentacją popularnych klientów MUD (zarówno stacjonarnych, jak i mobilnych), w której zazwyczaj szczegółowo opisano obsługiwane przez nie rozszerzenia (GMCP, MXP, MSDP itp.), obsługiwane zestawy znaków, sposób obsługi kolorów ANSI oraz ograniczenia dotyczące małych ekranów.
13. Ogromne domeny i nazwy hostów: widoczny chaos infrastruktury
Jeśli kiedykolwiek przeglądałeś rekordy DNS głównych dostawców hostingu, prawdopodobnie widziałeś ogromne listy nazw takich jak www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test i niezliczone warianty . Choć może się to wydawać bezsensowne, w rzeczywistości odzwierciedla to sposób organizacji infrastruktury obsługującej wiele MUD-ów i powiązanych usług.
Za jedną domeną kryją się setki subdomen: serwery baz danych, maszyny testujące, serwery proxy, systemy równoważenia obciążenia, usługi statystyczne, platformy poczty e-mail, pamięci masowe, sieci VPN … a często nawet port, na którym nasłuchuje MUD. W niektórych przypadkach gra toczy się w dyskretnej subdomenie; w innych dzieli adres IP z wieloma usługami, od forów po wiki i panele sterowania.
Ta proliferacja nazw jest istotna, jeśli myślisz o opublikowaniu swojego MUD-a na serwerze współdzielonym lub o skonfigurowaniu konkretnych serwerów proxy dla odtwarzaczy: musisz dokładnie skoordynować, które subdomeny wskazują na który komputer, które porty są otwarte i w jaki sposób zarządzane są zabezpieczenia, aby ruch Telnet nie zakłócał w niebezpieczny sposób innych ważnych usług.
14. Praktyczne uwagi dla klientów Telnet korzystających z urządzeń mobilnych
Granie w gry lub tworzenie oprogramowania przy użyciu klienta Telnet na urządzeniu mobilnym powoduje dodatkowe utrudnienia: mały ekran, klawiatura dotykowa, możliwe częste rozłączenia sieciowe, a czasami ograniczenia samych klientów w zakresie obsługi rozszerzeń.
Projektując serwer MUD, pamiętaj o kilku kwestiach:
- Unikaj zbyt długich kolejek: lepsze, krótsze akapity, dzięki którym użytkownik nie musi przewijać strony na boki.
- Umiarkuj użycie kodów ANSI Upewnij się, że nie psują one układu treści dla klientów, którzy nie potrafią ich właściwie zinterpretować.
- Należy zachować ostrożność przy paginacji. tak, aby doświadczenie nie było niemożliwą do zrozumienia ścianą tekstu.
- Wdrażaj miękkie ponowne połączeniaNa urządzeniach mobilnych łatwo stracić sygnał i nawiązać ponowne połączenie; serwer powinien to tolerować, nie przerywając sesji odtwarzacza przy pierwszej krótkiej przerwie.
Niektóre aplikacje klienckie przeznaczone dla urządzeń mobilnych, specjalizujące się w MUD-ach, zawierają już obsługę GMCP i innych rozszerzeń, dzięki czemu po ich wdrożeniu na serwerze można udostępniać klientom ustrukturyzowane informacje w postaci paneli, pasków stanu, szybkich map i innych pomocy wizualnych zamiast klasycznego tekstu.
15. Utwórz własny serwer MUD kompatybilny z istniejącymi klientami
Jeśli zdecydowałeś się napisać własny serwer MUD od podstaw, kluczem do uniknięcia izolacji jest respektowanie Telnetu jako warstwy bazowej i prawidłowe negocjowanie jego opcji . Nie musisz opracowywać protokołu na nowo, wystarczy postępować zgodnie ze sprawdzonymi konwencjami.
Krótko mówiąc, aby zapewnić kompatybilność z najpopularniejszymi klientami, należy:
- Wdrożyć Analiza poleceń Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
- Obsługa co najmniej kilku popularnych opcji: echo, lokalne tłumienie echa, GMCP Jeśli chcesz wzbogacić dane, a może i je skompresować.
- Wyślij tekst w formacie przyjaznym dla użytkownikaCRLF, ANSI opcjonalne, bez nadmiernego używania długich linii.
- Akceptuj dane wejściowe w trybie online i prawidłowo obsługuj podziały wierszy wysyłane przez klientów mobilnych.
Stamtąd możesz rozszerzyć swój serwer o dodatkowe protokoły lub nawet o własnego klienta, ale zaczynając od tej bazy, możesz testować swoją grę za pomocą istniejących klientów Telnet i korzystać z całego ekosystemu, który został stworzony wokół MUD-ów na przestrzeni lat.
Wszystkie te szczegóły dotyczące Telnetu, rozszerzeń, serwerów proxy, nazw hostów i specyfiki klienta mobilnego mogą początkowo wydawać się zawiłe, ale jeśli przeanalizujesz je krok po kroku, zobaczysz, że rdzeń jest dość prosty: przepływ tekstu z kilkoma dobrze zdefiniowanymi sekwencjami sterującymi. Rozumiejąc, jak tworzone są te wiadomości, jak negocjowane są opcje i czego oczekuje typowy klient, będziesz dysponować narzędziami potrzebnymi do zbudowania solidnego, kompatybilnego i przyjaznego dla użytkownika serwera MUD, dostępnego z dowolnego klienta Telnetu, zarówno na urządzeniu mobilnym, jak i na komputerze stacjonarnym.