Якщо ви вже деякий час граєтеся з текстовими MUD-іграми та клієнтами Telnet на своєму мобільному пристрої , ви, ймовірно, стикалися з тією ж проблемою: усі говорять про історію Telnet, ностальгію та анекдоти… але майже ніхто чітко не пояснює, як насправді взаємодіють клієнт і сервер. Ця стаття має на меті заповнити цю прогалину: заглибитися в протокол, повідомлення, послідовності керування та те, як зробити так, щоб ваш власний MUD-сервер безперебійно працював з існуючими клієнтами.
Ми детально та зрозуміло розглянемо, як працює типовий протокол MUD на основі Telnet , які розширення використовуються в галузі (GMCP, MSSP, стиснення тощо), як форматуються повідомлення, що очікує побачити мобільний клієнт і що потрібно надсилати з вашого сервера, щоб забезпечити безперебійну роботу без необхідності створювати протокол з нуля. Все це буде пояснено стандартною іспанською мовою (з Іспанії) з чіткими прикладами та без зайвого жаргону.
1. Telnet як основа: що насправді використовує більшість MUD
Більшість класичних MUD не винаходять нового транспорту: вони покладаються на Telnet як рівень зв'язку між клієнтом і сервером . Це означає, що зрештою надсилаються потоки байтів через TCP, де звичайний текст змішується зі спеціальними командами Telnet, яким передує байт 255 (0xFF).
З точки зору мережі, MUD-сервер поводиться як звичайний Telnet-сервер з безліччю додаткових розширень . Клієнт (мобільний, настільний або простий системний Telnet) встановлює TCP-з'єднання з портом MUD (часто 23, 4000, 5000 тощо), і звідти починається короткий обмін опціями.
Під час цих початкових переговорів обидві сторони надсилають одна одній керуючі послідовності Telnet типу "WILL", "WONT", "DO" та "DONT" для активації або деактивації функцій: луни, розміру вікна, додаткових протоколів, таких як GMCP, стиснення тощо. Все це передається разом з текстом гри, але клієнт може розрізнити це, оскільки керуючі команди позначені добре відомим символом 0xFF.
2. Скелет протоколу Telnet, що використовується MUD
У Telnet будь-яка керуюча команда починається з байта IAC (Інтерпретувати як команду, значення 255) . Далі йде один або кілька байтів, що вказують тип команди, а в багатьох випадках і код опції. На стандартному рівні протоколу MUD ви в основному зіткнетеся з:
- IAC DO«Я хочу, щоб ви (клієнт) активували цю опцію».
- IAC НЕ«Я не хочу, щоб ти скористався цією опцією».
- IAC WILL: «Я (сервер) можу і хочу використовувати цю опцію».
- IAC НЕ ЗВИЧАЙ«Я не збираюся використовувати цю опцію».
Ці параметри позначені номером; деякі з них є старими стандартами Telnet, інші — розширеннями, узгодженими у спільноті MUD (наприклад, GMCP, MSSP, COMPRESS2 ), які не згадуються в класичних RFC Telnet, але стали фактичним «псевдостандартом», оскільки основні клієнти їх підтримують.
Як MUD, ви зазвичай ініціюєте діалог, надсилаючи послідовності IAC DO/IAC WILL, щоб перевірити, що підтримує клієнт: чи приймає він GMCP, чи бажає він стиснення, чи пропонує він інформацію про термінал тощо. Клієнт відповість WILL/WONT або DO/DONT відповідно. Ваш сервер повинен враховувати ці відповіді та не використовувати опцію, якщо клієнт її не приймає.
3. Розділення між ігровим текстом та керуванням Telnet
Одне поширене питання — як розрізнити звичайний ігровий текст від команд керування . Правило просте: все, що не починається з 0xFF, вважається текстом. Команди Telnet завжди починаються з цього спеціального байта, саме для того, щоб уникнути плутанини.
Концептуальний приклад (вам не потрібно копіювати його дослівно, це лише для візуалізації): сервер може надсилати рядки опису середовища, а потім послідовність IAC для узгодження опції. Клієнт зчитує побайтово: коли він бачить 0xFF, він переходить у «командний режим»; решту часу він обробляє його як текст, застосовує ANSI-кольори, якщо це доречно, та відображає його.
Якщо вам коли-небудь знадобиться надіслати байт 0xFF як частину тексту (досить рідко, але можливо), ви повинні "екранувати" його, продублювавши . Тобто, щоб надіслати літерал 0xFF у потоці даних користувача, ви поспіль надсилаєте два 0xFF, і клієнт правильно інтерпретує їх як "один 0xFF тексту, а не команду".
4. Формат текстового повідомлення: рядки, розриви та кольори
Більшість контенту, який надсилатиме ваш MUD, складається з читабельних текстових повідомлень: описів, діалогів, списків об'єктів та команд . Хоча це може здатися тривіальним, варто звернути увагу на кілька деталей, щоб клієнти Telnet (особливо на мобільних пристроях) відображали його правильно.
Загалом, MUD все ще використовують класичний стиль рядків, що завершуються CRLF (\r\n) . Деякі клієнти підтримують лише LF (\n), але для максимальної сумісності завжди надсилайте знак повернення каретки, а потім знак переведення рядка.
Для кольору та форматування MUD зазвичай використовують ANSI-коди екранування, вбудовані в текст. Наприклад, послідовності, що починаються з ESC (0x1B), за якими йде «[31m» для червоного тексту, «[1m» для жирного шрифту тощо. Вони не є частиною самого протоколу Telnet, але розуміються більшістю терміналів та розширених MUD-клієнтів, включаючи багато мобільних клієнтів.
5. Розширення MUD через Telnet: GMCP, MSSP та компанія
Окрім звичайного тексту, багато MUD сьогодні поєднують Telnet з додатковими протоколами для обміну структурованими даними з клієнтами . Це дозволяє мобільним клієнтам відображати багатші інтерфейси, ніж простий текстовий потік.
Серед найчастіших розширень є:
- GMCP (Загальний протокол зв'язку MUD): надсилає інформацію у форматі JSON (хоча не завжди на 100% стандартному) про персонажа, карту, канали тощо.
- MSSP (Протокол стану Mud-сервера): призначений для надання даних сервера (назва MUD, кількість гравців, стать тощо) сервісам лістингу та цікавим клієнтам.
- СТИСНЕННЯ / СТИСНЕННЯ2Стиснення даних для зменшення пропускної здатності, що дуже цінується при повільних з'єднаннях.
Ці розширення узгоджуються так само, як і будь-який інший параметр Telnet: сервер зазвичай надсилає IAC WILL GMCP або IAC DO GMCP та очікує відповіді. Після узгодження розширення саме визначає, як інкапсулювати дані (наприклад, GMCP входить до підузгоджень Telnet: IAC SB <опція> … IAC SE).
6. Підузгодження (SB та SE): інкапсуляція спеціальних даних
Коли параметр Telnet вимагає надсилання більше даних, ніж просто так/ні, використовується підузгодження . Шаблон такий:
- IAC SB ІАК СЕ
У цьому блоці ви можете надсилати рядки, числа або певні структури, визначені розширенням . Наприклад, GMCP зазвичай надсилає щось дуже схоже на об'єкт JSON, з лапками, фігурними дужками та значеннями.
Коли клієнт отримує IAC SB GMCP, він знає, що все, що до IAC SE, є частиною пакета GMCP, а не звичайним потоком ігрового тексту. Це дозволяє йому чітко відокремити те, що йде до графічного інтерфейсу користувача, від того, що йде до класичного текстового буфера.
7. Що надсилає MUD-сервер: типовий потік зв'язку
Уявіть собі послідовність дій, починаючи з моменту підключення гравця з мобільного клієнта Telnet до вашого MUD-сервера :
- Клієнт відкриває TCP-з'єднання з портом MUD.
- Сервер надсилає вам вітальний банер (текст) і, ймовірно, деякі Послідовності IAC для торгівлі опціонами (відлуння, GMCP, стиснення…).
- Клієнт відповідає, приймаючи або відхиляючи ці варіанти за допомогою БУДУ/НЕ БУДУ та РОБИТИ/НЕ БУДУ.
- Звідти сервер надсилає екран входу (текст) та обробляє команди, які вводить гравець.
Сервер повинен завжди мати можливість зчитувати введений клієнтом текст як суміш тексту та команд Telnet , так само, як клієнт зчитує ваш вивід. Коли гравець друкує, наприклад, «північ» і натискає Enter, клієнт зазвичай надсилає цей рядок, а потім символ повернення каретки та переведення рядка. Ваш сервер зчитує до кінця рядка та інтерпретує його як команду від гравця.
Якщо клієнт вирішить ініціювати будь-який варіант (наприклад, запустити узгодження розміру вікна), ви також повинні бути готові отримувати послідовності IAC з боку клієнта та реагувати відповідно, а не навпаки.
8. Що надсилає клієнт Telnet (включно з мобільними клієнтами)
З точки зору вашого сервера, стандартний Telnet-клієнт (мобільний або настільний) надсилатиме вам два типи даних: текст користувача та команди Telnet . Текст зазвичай має кодування ASCII або UTF-8 залежно від клієнта; сьогодні краще використовувати принаймні UTF-8.
Команди Telnet, які ви отримуєте, є переважно відповідями на ваші запити на узгодження . Якщо ви надішлете `IAC DO GMCP`, клієнт відповість `IAC WILL GMCP`, якщо підтримує цю функцію, або `IAC WONT GMCP`, якщо ні. Він також може сам ініціювати деякі узгодження (наприклад, щодо типу терміналу).
Важливою деталлю для сумісності з мобільними пристроями є те, що багато сучасних клієнтів інтерпретують команди посимвольно або рядково, залежно від конфігурації . Рядково-рядкове розшифрування є більш поширеним, тому структуруйте свій синтаксичний аналізатор вхідних команд, думаючи про повні рядки, розділені символом \r\n, а не окремими символами.
9. Використання проксі-серверів та проблеми з мережею з MUD в обмежених мережах
У деяких середовищах (наприклад, корпоративних мережах, кампусах або певних операторах мобільного зв'язку) типові порти високої інтенсивності, що використовуються MUD, можуть бути заблоковані брандмауерами . У таких випадках гравці виявляють, що не можуть підключитися безпосередньо до порту MUD, навіть якщо сам Telnet дозволений на стандартних портах.
Класичне рішення передбачає використання проксі-сервера-посередника, який прослуховує дозволений порт (наприклад, порт Telnet 23 або порт FTP 21) і перенаправляє з'єднання на фактичний порт MUD. Проксі-сервер діє як міст: клієнт підключається до проксі-сервера, а проксі-сервер, за лаштунками, відкриває з'єднання з ігровим сервером.
Також часто колега з постійним підключенням до Інтернету встановлює проксі-сервер на свій комп'ютер і дозволяє іншим гравцям отримувати доступ до MUD через свою IP-адресу . Однак, потрібно бути обережним зі спільними IP-адресами: якщо кілька облікових записів підключаються з однієї IP-адреси, деякі MUD можуть інтерпретувати це як незаконний багатокористувацький режим і накладати штрафи. В ідеалі, вам слід повідомити адміністраторів гри, якщо ви плануєте регулярно ділитися своєю IP-адресою.
10. Обмеження та ризики проксі-вимірювань для MUD
Хоча проксі-сервер може врятувати вас у дуже закритих мережах, сьогодні надійних публічних анонімних проксі-серверів небагато , а ті, що залишилися, зазвичай перевантажені, не працюють або блокуються з міркувань безпеки.
Крім того, ті ж мережі, що блокують порти з високим рівнем доступу, також можуть мати заблокований порт 8080 , що дуже поширене явище для HTTP-проксі. Тому, якщо хтось налаштовує приватний проксі для доступу до MUD, бажано розмістити його на порту, який майже ніколи не фільтрується (23, 21 або інший дуже поширений та дозволений порт у відповідній мережі).
Не забувайте, що ці налаштування мають значення для безпеки: трафік проходить через посередницький комп'ютер, а сесії, паролі тощо можуть бути записані в журнал. З точки зору проектування MUD-сервера, протокол не змінюється, але вам доведеться припустити, що багато з'єднань будуть "обгорнуті" через проксі-сервер , що потенційно призведе до додаткової затримки або частіших розривів з'єднання.
11. Приклад наративної взаємодії в текстовому MUD
Окрім технічних аспектів, текстова MUD спирається на багаті описи та атмосферу . Багато ігор містять знакові текстові фрагменти, літературні цитати або майже поетичні фрагменти, які сервер дослівно надсилає клієнту, щоб покращити занурення гравця.
Наприклад, своєрідна «літанія проти страху» може з’явитися на екрані , коли персонаж стикається з вирішальним моментом. Технічно це не що інше, як послідовність рядків тексту з відповідними розривами та, за бажанням, певним кольором або форматуванням. Але з точки зору користувацького досвіду це має значний вплив.
Цей тип тексту, хоча й не змінює протокол Telnet, впливає на те, як ви обробляєте міжрядковий інтервал, нумерацію сторінок та частоту оновлення . Якщо ви відображаєте кілька довгих абзаців одним потоком, вони можуть стати нечитабельними на маленьких екранах (наприклад, мобільних телефонів). Ось чому багато серверів використовують системи «нумерації сторінок», які призупиняють вивід після певної кількості рядків і чекають, поки програвач натисне клавішу для продовження.
12. Зовнішні ресурси та додаткова технічна документація
На відміну від інших високостандартизованих протоколів, екосистема MUD підживлюється розрізненими документами, академічними PDF-файлами та вільними статтями, що описують варіанти, пропозиції розширення та дослідження взаємодії в середовищах MUD.
У університетських репозиторіях та цифрових бібліотеках доступні роботи, які аналізують клієнт-серверну архітектуру MUD, еволюцію від простого Telnet до багатофункціональних протоколів і навіть проблеми взаємодії з користувачем у текстових інтерфейсах. Хоча багато з цих документів не пояснюють покроково, як форматувати повідомлення, вони пропонують корисний контекст для розуміння того, чому були прийняті певні протоколи та як вони поєднуються.
Для доповнення реалізації також доцільно переглянути документацію популярних MUD-клієнтів (як настільних, так і мобільних), де зазвичай детально описано, які розширення вони підтримують (GMCP, MXP, MSDP тощо), які набори символів вони обробляють, як вони працюють з кольорами ANSI та які обмеження вони мають на малих екранах.
13. Великі домени та імена хостів: видимий хаос інфраструктури
Якщо ви коли-небудь переглядали DNS-записи основних хостинг-провайдерів, ви, ймовірно, бачили величезні списки імен, таких як www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test та безліч їх варіацій . Хоча це може здатися шумом, насправді це відображає те, як організована інфраструктура, що розміщує багато MUD та пов'язаних з ними сервісів.
За одним доменом можуть бути знайдені сотні піддоменів: сервери баз даних, тестові машини, проксі-сервери, балансувальники навантаження, сервіси статистики, поштові платформи, сховища, VPN … і часто навіть порт, на якому прослуховується MUD. У деяких випадках гра ведеться на окремому піддомені; в інших він використовує спільну IP-адресу з низкою сервісів, починаючи від форумів і закінчуючи вікі та панелями керування.
Таке поширення імен є актуальним, якщо ви плануєте опублікувати свій MUD на спільному сервері або налаштувати спеціальні проксі-сервери для гравців: вам потрібно буде ретельно узгодити, які піддомени вказують на яку машину, які порти відкриваються та як керується безпека, щоб трафік Telnet не створював небезпечних перешкод для інших критично важливих служб.
14. Практичні міркування для клієнтів Telnet на мобільних пристроях
Гра в ігри або розробка за допомогою клієнта Telnet на мобільному пристрої додає рівень складності: маленький екран, сенсорна клавіатура, можливі часті відключення від мережі, а іноді й обмеження самих клієнтів щодо підтримки розширень.
Під час проектування вашого MUD-сервера пам'ятайте про кілька моментів:
- Уникайте надмірно довгих чергкраще робити короткі абзаци, щоб користувачеві не доводилося гортати сторінку з боку в бік.
- Помірне використання кодів ANSI І переконайтеся, що вони не порушують макет для клієнтів, які погано їх інтерпретують.
- Обережно поводьтеся з пагінацією. щоб досвід не був стіною тексту, яку неможливо відстежити.
- Реалізація м'яких перепідключеньНа мобільному пристрої легко втратити сигнал і підключитися знову; ваш сервер повинен це терпіти, не перериваючи сеанс гравця при першому ж короткочасному перериванні.
Деякі мобільні клієнти, що спеціалізуються на MUD, вже включають підтримку GMCP та інших розширень, тому, якщо ви реалізуєте їх на сервері, ви можете запропонувати структуровану інформацію, яку клієнт відображає у вигляді панелей, індикаторів здоров'я, швидких карт та інших візуальних посібників поверх класичного тексту.
15. Створіть власний MUD-сервер, сумісний з існуючими клієнтами
Якщо ви вирішили написати власний MUD-сервер з нуля, ключем до уникнення ізоляції є повага до Telnet як базового рівня та правильне узгодження його параметрів . Вам не потрібно винаходити протокол заново, а краще дотримуватися перевірених домовленостей.
Коротше кажучи, щоб бути сумісним з найпоширенішими клієнтами, вам слід:
- Реалізувати Розбір команд Telnet (IAC, РОБИТИ, НЕ, БУДЕ, НЕ ЗВИЧАЙУ, SB, SE).
- Підтримайте принаймні деякі поширені варіанти: луна, локальне придушення луни, GMCP Якщо вам потрібні збагачені дані, а можливо, й стиснення.
- послати текст у зручному для користувача форматіCRLF, ANSI необов'язкові, без надмірного використання довгих рядків.
- Приймати вхідні дані в онлайн-режимі та правильно обробляти розриви рядків, надіслані мобільними клієнтами.
Звідти ви можете розширити свій сервер додатковими протоколами або навіть власним клієнтом, але починаючи з цієї бази, ви зможете протестувати свою гру з існуючими клієнтами Telnet та скористатися перевагами всієї екосистеми, яка була створена навколо MUD протягом багатьох років.
Усі ці особливості Telnet, розширення, проксі-сервери, імена хостів та мобільних клієнтів можуть спочатку здатися заплутаними, але якщо ви розберете їх крок за кроком, то побачите, що ядро досить просте: текстовий потік з кількома чітко визначеними послідовностями керування. Розуміючи, як формуються ці повідомлення, як узгоджуються параметри та що очікує побачити типовий клієнт, ви матимете інструменти, необхідні для створення надійного, сумісного та зручного MUD-сервера, доступного з будь-якого клієнта Telnet, чи то на мобільному пристрої, чи на настільному комп'ютері.