Pokud si již nějakou dobu hrajete s textovými MUD hrami a Telnet klienty na svém mobilním zařízení , pravděpodobně jste narazili na stejný problém: všichni mluví o historii Telnetu, nostalgii a anekdotách… ale téměř nikdo jasně nevysvětluje, jak klient a server ve skutečnosti komunikují. Tento článek si klade za cíl tuto mezeru zaplnit: ponořit se do protokolu, zpráv, řídicích sekvencí a toho, jak zajistit, aby váš vlastní MUD server bezproblémově fungoval se stávajícími klienty.
Důkladně a přímočaře se podíváme na to, jak funguje typický protokol MUD založený na Telnetu , jaké rozšíření se v oboru používají (GMCP, MSSP, komprese atd.), jak se formátují zprávy, co mobilní klient očekává a co je třeba odeslat ze serveru, aby vše probíhalo hladce, aniž byste museli vytvářet protokol od nuly. To vše bude vysvětleno ve standardní španělštině (ze Španělska) s jasnými příklady a bez zbytečného žargonu.
1. Telnet jako základ: co většina MUDů skutečně používá
Většina klasických MUDů nevynalézá žádný nový transport: spoléhají se na Telnet jako komunikační vrstvu mezi klientem a serverem . To znamená, že nakonec se odesílají bajtové proudy přes TCP, kde je normální text smíchán se speciálními Telnetovými příkazy, kterým předchází bajt 255 (0xFF).
Server MUD se z pohledu sítě chová jako základní Telnet server s řadou volitelných rozšíření . Klient (ať už mobilní, stolní nebo jednoduchý systémový Telnet) naváže TCP spojení s portem MUD (často 23, 4000, 5000 atd.) a odtud začíná krátká výměna voleb.
V tomto počátečním vyjednávání si obě strany posílají řídicí sekvence Telnetu typu „WILL“, „WONT“, „DO“ a „DONT“ pro aktivaci nebo deaktivaci funkcí: echo, velikost okna, další protokoly jako GMCP, komprese atd. To vše putuje smíchané s herním textem, ale klient to dokáže rozlišit, protože řídicí příkazy jsou označeny známým 0xFF.
2. Kostra protokolu Telnet používaného MUDy
V Telnetu začíná jakýkoli řídicí příkaz bajtem IAC (Interpret As Command, hodnota 255) . Následuje jeden nebo více bajtů označujících typ příkazu a v mnoha případech i kód volby. Na úrovni standardního protokolu MUD se setkáte především s:
- IAC DO"Chci, abyste (klient) tuto možnost aktivovali."
- IAC NE"Nechci, abys tuto možnost využil/a."
- IAC WILL„Já (server) mohu a chci tuto možnost použít.“
- IAC NEBUDE"Tuto možnost nevyužiji."
Možnosti jsou označeny číslem; některé jsou staré standardy Telnetu, jiné jsou rozšíření dohodnutá v komunitě MUD (např. GMCP, MSSP, COMPRESS2 ), která se neobjevují v klasických dokumentech RFC pro Telnet, ale stala se de facto „pseudostandardem“, protože je hlavní klienti podporují.
Jako MUD obvykle zahájíte dialog odesláním sekvencí IAC DO/IAC WILL, abyste otestovali, co klient podporuje: zda přijímá GMCP, zda chce kompresi, zda nabízí informace o terminálu atd. Klient odpoví WILL/WONT nebo DO/DONT podle potřeby. Váš server musí tyto odpovědi respektovat a nepoužívat žádnou možnost, pokud ji klient neakceptuje.
3. Oddělení herního textu a ovládání přes Telnet
Jednou z častých otázek je, jak rozlišit mezi běžným herním textem a ovládacími příkazy . Pravidlo je jednoduché: cokoli, čemu nepředchází 0xFF, je považováno za text. Telnetové příkazy vždy začínají tímto speciálním bajtem, právě proto, aby se předešlo nejasnostem.
Konceptuální příklad (nemusíte ho doslovně kopírovat, je to jen pro vizualizaci): server může odeslat řádky popisu prostředí následované sekvencí IAC pro vyjednání možnosti. Klient čte bajt po bajtu: když vidí 0xFF, přejde do „příkazového režimu“; po zbytek času jej považuje za text, v případě potřeby použije barvy ANSI a zobrazí jej.
Pokud někdy potřebujete odeslat bajt 0xFF jako součást textu (což je poměrně vzácné, ale možné), musíte ho „uniknout“ jeho duplikací . To znamená, že pro odeslání literálu 0xFF v datovém proudu uživatelské oblasti odešlete dva 0xFF za sebou a klient je správně interpretuje jako „jeden 0xFF textu, nikoli příkaz“.
4. Formát textové zprávy: řádky, zalomení a barvy
Většina obsahu, který váš MUD odešle, se skládá z čitelných textových zpráv: popisů, dialogů, seznamů objektů a příkazů . I když se to může zdát triviální, stojí za to věnovat pozornost několika detailům, aby klienti Telnetu (zejména na mobilních zařízeních) obsah zobrazovali správně.
MUDy obecně stále používají klasický styl řádků ukončených CRLF (\r\n) . Někteří klienti podporují pouze LF (\n), ale pro maximální kompatibilitu vždy odesílejte znak konce řádku následovaný znakem posunu řádku.
Pro barvy a formátování MUD obvykle používají ANSI escape kódy vložené do textu. Například sekvence začínající ESC (0x1B) následované „[31m“ pro červený text, „[1m“ pro tučné písmo atd. Tyto kódy nejsou součástí samotného protokolu Telnet, ale rozumí jim většina terminálů a pokročilých MUD klientů, včetně mnoha mobilních klientů.
5. Rozšíření MUD přes Telnet: GMCP, MSSP a společnost
Kromě prostého textu dnes mnoho MUD kombinuje Telnet s dalšími protokoly pro výměnu strukturovaných dat s klienty . To umožňuje mobilním klientům zobrazovat bohatší rozhraní než jednoduchý textový proud.
Mezi nejčastější rozšíření patří:
- GMCP (obecný komunikační protokol MUD): odesílá informace ve formátu JSON (i když ne vždy 100% standardním) o postavě, mapě, kanálech atd.
- MSSP (Mud Server Status Protocol): navrženo tak, aby poskytovalo data serveru (název MUD, počet hráčů, pohlaví atd.) inzertním službám a zvědavým klientům.
- KOMPRES / KOMPRES 2Komprese dat pro snížení šířky pásma, vysoce ceněná u pomalých připojení.
Tato rozšíření jsou vyjednávána stejně jako jakékoli jiné možnosti Telnetu: server obvykle odesílá IAC WILL GMCP nebo IAC DO GMCP a čeká na odpověď. Po odsouhlasení rozšíření samo definuje, jak zapouzdřit data (například GMCP je součástí podvyjednávání Telnetu: IAC SB <možnost> … IAC SE).
6. Subnegociace (SB a SE): zapouzdření speciálních dat
Pokud volba Telnetu vyžaduje odeslání více dat než jen jednoduchého ano/ne, použije se podvyjednávání . Vzor je následující:
- IAC SB IAC SE
V rámci tohoto bloku můžete odesílat řetězce, čísla nebo specifické struktury definované příponou . Například GMCP obvykle odesílá něco velmi podobného objektu JSON s uvozovkami, složenými závorkami a hodnotami.
Když klient obdrží IAC SB GMCP, ví, že vše až do IAC SE je součástí balíčku GMCP a nikoli normálního textového streamu hry. To mu umožňuje jasně oddělit, co jde do grafického rozhraní, od toho, co jde do klasického textového bufferu.
7. Co odesílá MUD server: typický komunikační tok
Představte si sekvenci od okamžiku, kdy se hráč připojí z mobilního Telnet klienta k vašemu MUD serveru :
- Klient otevře TCP spojení s portem MUD.
- Server vám pošle uvítací banner (text) a pravděpodobně i nějaké IAC sekvence pro obchodování s opcemi (echo, GMCP, komprese…).
- Zákazník reaguje přijetím nebo odmítnutím těchto možností pomocí BUDU/NEBUDU a UDĚLÁM/NEBUDU.
- Odtud server odesílá přihlašovací obrazovku (text) a zpracovává příkazy, které hráč zadá.
Server musí být vždy schopen číst vstup klienta jako kombinaci textu a příkazů Telnet , stejně jako klient čte váš výstup. Když hráč například napíše „north“ a stiskne Enter, klient obvykle odešle tento řetězec následovaný znakem návratu vozíku a posunem řádku. Váš server přečte text do konce řádku a interpretuje jej jako příkaz od hráče.
Pokud se klient rozhodne iniciovat jakoukoli možnost (například spustit vyjednávání velikosti okna), musíte být také připraveni přijímat sekvence IAC ze strany klienta a reagovat odpovídajícím způsobem, nikoli pouze naopak.
8. Co odesílá klient Telnet (včetně mobilních klientů)
Z pohledu vašeho serveru vám standardní Telnet klient (mobilní nebo desktopový) v podstatě odešle dva typy věcí: uživatelský text a Telnet příkazy . Text je obvykle ASCII nebo UTF-8 v závislosti na klientovi; v dnešní době je nejlepší předpokládat alespoň UTF-8.
Příkazy Telnetu, které obdržíte, jsou primárně odpověďmi na vaše požadavky na vyjednávání . Pokud odešlete příkaz `IAC DO GMCP`, klient odpoví `IAC WILL GMCP`, pokud jej podporuje, nebo `IAC WONT GMCP`, pokud jej nepodporuje. Může také sám zahájit vyjednávání (například ohledně typu terminálu).
Důležitým detailem pro kompatibilitu s mobilními zařízeními je, že mnoho moderních klientů interpretuje příkazy znak po znaku nebo řádek po řádku, v závislosti na konfiguraci . Řádek po řádku je běžnější, proto strukturujte analyzátor vstupu příkazů jako celé řádky oddělené znakem \r\n, nikoli jednotlivé znaky.
9. Používání proxy serverů a síťové problémy s MUD v omezených sítích
V některých prostředích (např. v podnikových sítích, kampusech nebo u některých mobilních operátorů) mohou být typické porty s vysokou zátěží používané MUD blokovány firewally . V těchto případech hráči zjistí, že se nemohou připojit přímo k portu MUD, i když je samotný Telnet na standardních portech povolen.
Klasické řešení zahrnuje použití zprostředkující proxy, která naslouchá na povoleném portu (například Telnet port 23 nebo FTP port 21) a přesměruje připojení na skutečný port MUD. Proxy funguje jako most: klient se připojuje k proxy a proxy v zákulisí otevírá připojení k hernímu serveru.
Je také běžné, že si kolega s trvalým připojením k internetu nainstaluje na svůj počítač proxy a umožní ostatním hráčům přístup k MUD prostřednictvím své IP adresy . S sdílenými IP adresami je však třeba být opatrný: pokud se ze stejné IP adresy připojuje více účtů, některé MUDy to mohou interpretovat jako nelegální multiplayer a udělit penalizaci. V ideálním případě byste měli informovat administrátory hry, pokud plánujete pravidelně sdílet svou IP adresu.
10. Omezení a rizika zástupných metod pro MUD
Přestože vás proxy může zachránit ve velmi uzavřených sítích, v dnešní době není mnoho spolehlivých veřejných anonymních proxy serverů a těch pár, které zbydou, je obvykle přetížených, nefunkčních nebo blokovaných z bezpečnostních důvodů.
Navíc tytéž sítě, které blokují porty s vysokým limitem, mohou mít blokovaný i port 8080 , což je u HTTP proxy velmi běžné. Pokud si tedy někdo nastaví soukromou proxy pro přístup k MUD, je vhodné ji umístit na port, který téměř nikdy není filtrován (23, 21 nebo jiný velmi běžný a povolený port v dané síti).
Nezapomeňte, že tato nastavení mají bezpečnostní důsledky: provoz prochází zprostředkujícím počítačem a lze protokolovat relace, hesla atd. Z pohledu návrhu MUD serveru se protokol nemění, ale budete muset předpokládat, že mnoho připojení bude „zabaleno“ přes proxy , což může vést k delší latenci nebo častějším odpojováním.
11. Příklad narativní interakce v rámci textového MUD
Kromě technických aspektů se textový MUD spoléhá na bohaté popisy a atmosféru . Mnoho her obsahuje ikonické textové úryvky, literární citáty nebo téměř poetické fragmenty, které server doslovně posílá klientovi, aby se zvýšila hratelnost.
Například se na obrazovce může objevit jakási „litanie proti strachu“, když postava čelí klíčovému okamžiku. Technicky vzato se nejedná o nic jiného než o posloupnost řádků textu s vhodnými přerušeními a v případě potřeby i o barvu nebo formátování. Z hlediska uživatelské zkušenosti to však má významný dopad.
Tento typ textu, i když nemění protokol Telnet, ovlivňuje způsob, jakým se zpracovává řádkování, stránkování a obnovovací frekvence . Pokud zobrazíte několik dlouhých odstavců najednou, mohou se stát nečitelnými na malých obrazovkách (například v mobilních telefonech). Proto mnoho serverů implementuje systémy „stránkování“, které pozastaví výstup po určitém počtu řádků a čekají, až přehrávač stiskne klávesu pro pokračování.
12. Externí zdroje a další technická dokumentace
Na rozdíl od jiných vysoce standardizovaných protokolů je ekosystém MUD poháněn rozptýlenými dokumenty, akademickými PDF soubory a volnými články popisujícími varianty, návrhy rozšíření a studie o interakci v prostředích MUD.
V univerzitních repozitářích a digitálních knihovnách jsou k dispozici práce, které analyzují architekturu klient-server MUD, vývoj od holého Telnetu k bohatým protokolům a dokonce i problémy s uživatelskou zkušeností v textových rozhraních. Ačkoli mnoho z těchto dokumentů neučí řádek po řádku, jak formátovat zprávy, nabízejí užitečný kontext pro pochopení, proč byly určité protokoly přijaty a jak jsou kombinovány.
Pro doplnění implementace je také vhodné prostudovat dokumentaci k populárním MUD klientům (pro stolní počítače i mobilní zařízení), kde je obvykle podrobně popsáno, která rozšíření podporují (GMCP, MXP, MSDP atd.), jaké znakové sady zpracovávají, jak pracují s barvami ANSI a jaká mají omezení na malých obrazovkách.
13. Obrovské domény a názvy hostitelů: Viditelný chaos infrastruktury
Pokud jste se někdy podívali na DNS záznamy hlavních poskytovatelů hostingu, pravděpodobně jste viděli obrovské seznamy názvů jako www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test a nespočet variant . I když se to může zdát jako šum, ve skutečnosti to odráží, jak je organizována infrastruktura hostující mnoho MUD a souvisejících služeb.
Za jedinou doménou se skrývají stovky subdomén: databázové servery, testovací stroje, proxy, vyvažovače zátěže, statistické služby, e-mailové platformy, úložiště, VPN … a často i port, na kterém MUD naslouchá. V některých případech se hra hraje na diskrétní subdoméně, v jiných sdílí IP adresu s řadou služeb od fór přes wiki až po ovládací panely.
Toto šíření názvů je relevantní, pokud uvažujete o publikování svého MUD na sdíleném serveru nebo o nastavení specifických proxy serverů pro hráče: budete muset pečlivě koordinovat, které subdomény odkazují na který počítač, které porty jsou otevřeny a jak je řízeno zabezpečení, aby provoz Telnetu nebezpečně nerušil další kritické služby.
14. Praktické aspekty pro zákazníky Telnetu na mobilních zařízeních
Hraní her nebo vývoj s Telnet klientem na mobilním zařízení přidává další vrstvu komplikací: malou obrazovku, dotykovou klávesnici, možná častá odpojování od sítě a někdy i omezení samotných klientů, pokud jde o podporu rozšíření.
Při návrhu MUD serveru mějte na paměti několik bodů:
- Vyhněte se příliš dlouhým frontámlepší kratší odstavce, aby uživatel nemusel posouvat ze strany na stranu.
- Moderujte používání kódů ANSI A ujistěte se, že nenarušují rozvržení pro klienty, kteří je neinterpretují dobře.
- S stránkováním zacházejte opatrně. aby zážitek nebyl nesledovatelnou zdí textu.
- Implementace měkkých opětovných připojeníNa mobilních zařízeních je snadné ztratit signál a znovu se připojit; váš server by to měl tolerovat, aniž by přerušil relaci hráče při prvním krátkém přerušení.
Někteří mobilní klienti specializující se na MUDy již obsahují podporu pro GMCP a další rozšíření, takže pokud je implementujete na serveru, můžete nabídnout strukturované informace, které klient zobrazuje jako panely, ukazatele zdraví, rychlé mapy a další vizuální pomůcky přes klasický text.
15. Vytvořte si vlastní MUD server kompatibilní se stávajícími klienty
Pokud jste se rozhodli napsat si vlastní MUD server od nuly, klíčem k vyhnutí se izolaci je respektovat Telnet jako základní vrstvu a správně vyjednávat jeho možnosti . Nemusíte protokol znovu vynalézat, ale raději se řídit osvědčenými konvencemi.
Stručně řečeno, abyste byli kompatibilní s nejběžnějšími klienty, měli byste:
- Implementovat Analýza příkazů Telnetu (IAC, UDĚLAT, NEDĚLAT, BUDU, ZVYKNĚM, SB, SE).
- Podporujte alespoň některé běžné možnosti: ozvěna, lokální potlačení ozvěny, GMCP Pokud chcete obohacená data a možná i kompresi.
- Odeslat text v uživatelsky přívětivém formátuCRLF, ANSI volitelné, bez nadměrného používání dlouhých řádků.
- Přijímat vstupy v online režimu a správně zpracovávat zalomení řádků odeslaná mobilními klienty.
Odtud můžete rozšířit svůj server o další protokoly nebo dokonce o vlastního klienta, ale vycházet z této základny vám umožní otestovat hru se stávajícími Telnet klienty a využít celý ekosystém, který byl v průběhu let vytvořen kolem MUDů.
Všechen tento Telnet, rozšíření, proxy, názvy hostitelů a zvláštnosti mobilních klientů se mohou zpočátku zdát matoucí, ale pokud si to rozeberete krok za krokem, uvidíte, že jádro je docela jednoduché: textový tok s několika dobře definovanými řídicími sekvencemi. Pochopením toho, jak se tyto zprávy tvoří, jak se vyjednávají možnosti a co typický klient očekává, budete mít nástroje, které potřebujete k vytvoření robustního, kompatibilního a uživatelsky přívětivého MUD serveru, který bude přístupný z jakéhokoli Telnet klienta, ať už na mobilním zařízení nebo stolním počítači.