Ja jau kādu laiku esat eksperimentējis ar teksta MUD spēlēm un Telnet klientiem savā mobilajā ierīcē , iespējams, esat saskāries ar to pašu problēmu: visi runā par Telnet vēsturi, nostalģiju un anekdotēm… bet gandrīz neviens skaidri nepaskaidro, kā klients un serveris faktiski sazinās. Šī raksta mērķis ir aizpildīt šo robu: iedziļināties protokolā, ziņojumos, vadības secībās un to, kā panākt, lai jūsu MUD serveris nemanāmi darbotos ar esošajiem klientiem.
Mēs rūpīgi un vienkārši aplūkosim, kā darbojas tipisks Telnet balstīts MUD protokols , kādi paplašinājumi tiek izmantoti nozarē (GMCP, MSSP, saspiešana utt.), kā tiek formatēti ziņojumi, ko mobilais klients sagaida redzēt un kas jums jānosūta no servera, lai nodrošinātu, ka viss darbojas nevainojami, neveidojot protokolu no nulles. Tas viss tiks izskaidrots standarta spāņu valodā (no Spānijas), ar skaidriem piemēriem un bez lieka žargona.
1. Telnet kā bāze: ko faktiski izmanto lielākā daļa MUD ierīču
Lielākā daļa klasisko MUD neizgudro jaunu transportēšanas veidu: tie paļaujas uz Telnet kā komunikācijas slāni starp klientu un serveri . Tas nozīmē, ka galu galā tiek nosūtītas baitu plūsmas, izmantojot TCP, kur parasts teksts tiek sajaukts ar īpašām Telnet komandām, pirms kurām atrodas 255. baits (0xFF).
No tīkla viedokļa MUD serveris darbojas kā vienkāršs Telnet serveris ar virkni papildu paplašinājumu . Klients (mobilais, galddators vai vienkāršs sistēmas Telnet) izveido TCP savienojumu ar MUD portu (bieži vien 23, 4000, 5000 utt.), un no turienes sākas īsa opciju apmaiņa.
Šajās sākotnējās sarunās abas puses viena otrai nosūta Telnet vadības secības ar tipu "WILL", "WONT", "DO" un "DONT", lai aktivizētu vai deaktivizētu funkcijas: atbalsi, loga izmēru, papildu protokolus, piemēram, GMCP, saspiešanu utt. Tas viss pārvietojas sajaukts ar spēles tekstu, bet klients to var atšķirt, jo vadības komandas ir apzīmētas ar labi zināmo 0xFF.
2. MUD izmantotā Telnet protokola skelets
Telnet tīklā jebkura vadības komanda sākas ar IAC (interpretēt kā komandu, vērtība 255) baitu . Tam seko viens vai vairāki baiti, kas norāda komandas veidu un daudzos gadījumos opcijas kodu. Standarta MUD protokola līmenī galvenokārt sastapsiet:
- IAC DO"Es vēlos, lai jūs (klients) aktivizētu šo opciju."
- IAC NEDARA"Es nevēlos, lai tu izmantotu šo iespēju."
- IAC BŪS: “Es (serveris) varu un vēlos izmantot šo opciju.”
- IAC PARADĪJUMS"Es neizmantošu šo iespēju."
Iespējas ir apzīmētas ar numuru; daži ir veci Telnet standarti, citi ir paplašinājumi, par kuriem panākta vienošanās MUD kopienā (piemēram, GMCP, MSSP, COMPRESS2 ), kas neparādās klasiskajos Telnet RFC, bet ir kļuvuši par de facto "pseidostandartu", jo galvenie klienti tos atbalsta.
Kā MUD, jūs parasti sākat dialogu, nosūtot IAC DO/IAC WILL secības, lai pārbaudītu, ko klients atbalsta: vai tas pieņem GMCP, vai tas vēlas saspiešanu, vai tas piedāvā termināļa informāciju utt. Klients atbildēs ar WILL/WONT vai DO/DONT atkarībā no tā, kas nepieciešams. Jūsu serverim ir jārespektē šīs atbildes un tas nedrīkst izmantot opciju, ja klients to nepieņem.
3. Spēles teksta un Telnet vadības atdalīšana
Viens bieži uzdots jautājums ir, kā atšķirt parasto spēles tekstu no vadības komandām . Noteikums ir vienkāršs: viss, kam nav priekšā 0xFF, tiek uzskatīts par tekstu. Telnet komandas vienmēr sākas ar šo īpašo baitu, tieši tāpēc, lai izvairītos no neskaidrībām.
Konceptuāls piemērs (nav nepieciešams to kopēt burtiski, tas ir paredzēts tikai vizualizācijai): serveris var nosūtīt vides apraksta rindiņas, kam seko IAC secība, lai vienotos par opciju. Klients lasa baitu pa baitam: kad tas redz 0xFF, tas pāriet "komandrežīmā"; pārējā laikā tas to apstrādā kā tekstu, ja nepieciešams, piemēro ANSI krāsu un parāda to.
Ja jums kādreiz ir jānosūta 0xFF baits kā daļa no teksta (diezgan reti, bet iespējams), jums tas ir "jāizslēdz", dublējot to . Tas ir, lai lietotāja datu plūsmā nosūtītu literālu 0xFF, jūs nosūtāt divus 0xFF pēc kārtas, un klients tos pareizi interpretē kā "vienu 0xFF teksta daļu, nevis komandu".
4. Īsziņu formāts: rindas, pārtraukumi un krāsas
Lielākā daļa satura, ko nosūtīs jūsu MUD, sastāvēs no salasāmām teksta ziņām: aprakstiem, dialogiem, objektu sarakstiem un komandām . Lai gan tas var šķist triviāli, ir vērts pievērst uzmanību dažām detaļām, lai nodrošinātu, ka Telnet klienti (īpaši mobilajās ierīcēs) to pareizi attēlo.
Kopumā MUD joprojām izmanto klasisko rindu stilu, kas beidzas ar CRLF (\r\n) . Daži klienti atbalsta tikai LF (\n), taču maksimālas saderības nodrošināšanai vienmēr jānosūta rakstatgrieze, kam seko rindiņas padeve.
Krāsai un formatējumam MUD parasti izmanto tekstā iegultus ANSI iziešanas kodus . Piemēram, secības, kas sākas ar ESC (0x1B), kam seko “[31m” sarkanam tekstam, “[1m” treknrakstam utt. Tās nav daļa no paša Telnet protokola, bet tās saprot lielākā daļa termināļu un uzlabotu MUD klientu, tostarp daudzi mobilie klienti.
5. MUD paplašinājumi, izmantojot Telnet: GMCP, MSSP un uzņēmums
Papildus vienkāršam tekstam daudzi mūsdienu MUD apvieno Telnet ar papildu protokoliem, lai apmainītos ar strukturētiem datiem ar klientiem . Tas ļauj mobilajiem klientiem attēlot bagātīgākas saskarnes nekā vienkārša teksta plūsma.
Starp visbiežāk sastopamajiem paplašinājumiem ir:
- GMCP (vispārējais MUD saziņas protokols): nosūta informāciju JSON formātā (lai gan ne vienmēr 100% standarta formātā) par tēlu, karti, kanāliem utt.
- MSSP (dubļu servera statusa protokols): paredzēts servera datu (MUD nosaukums, spēlētāju skaits, dzimums utt.) sniegšanai sarakstu pakalpojumiem un ziņkārīgiem klientiem.
- SASPIEST / SASPIEST2Datu saspiešana, lai samazinātu joslas platumu, kas ir ļoti vērtīga lēnos savienojumos.
Šie paplašinājumi tiek saskaņoti tāpat kā jebkura cita Telnet opcija: serveris parasti nosūta IAC WILL GMCP vai IAC DO GMCP un gaida atbildi. Kad vienošanās ir panākta, pats paplašinājums nosaka, kā iekapsulēt datus (piemēram, GMCP ietilpst Telnet apakšsarunās: IAC SB <opcija> … IAC SE).
6. Apakšsarunas (SB un SE): īpašu datu iekapsulēšana
Ja Telnet opcijai ir jānosūta vairāk datu nekā vienkārša jā/nē, tiek izmantota apakšsarunu metode . Modelis ir šāds:
- IAC SB IAC SE
Šajā blokā var nosūtīt virknes, skaitļus vai noteiktas struktūras, ko definē paplašinājums . Piemēram, GMCP parasti nosūta kaut ko ļoti līdzīgu JSON objektam, izmantojot pēdiņas, cirtainās figūriekavas un vērtības.
Kad klients saņem IAC SB GMCP, tas zina, ka viss līdz IAC SE ir daļa no GMCP pakotnes, nevis parastā spēles teksta plūsma. Tas ļauj skaidri nodalīt to, kas nonāk grafiskajā lietotāja saskarnē, no tā, kas nonāk klasiskajā teksta buferī.
7. Ko nosūta MUD serveris: tipiska saziņas plūsma
Iedomājieties secību no brīža, kad spēlētājs izveido savienojumu no mobilā Telnet klienta uz jūsu MUD serveri :
- Klients atver TCP savienojumu ar MUD portu.
- Serveris nosūta jums apsveikuma baneri (tekstu) un, iespējams, arī kādu IAC secības opciju tirdzniecībai (atbalss, GMCP, saspiešana…).
- Klients atbild, pieņemot vai noraidot šīs iespējas ar WILL/WONT un DO/DONT.
- No turienes serveris nosūta pieteikšanās ekrānu (tekstu) un apstrādā komandas, ko spēlētājs ieraksta.
Serverim vienmēr jāspēj nolasīt klienta ievadi kā teksta un Telnet komandu maisījumu , tāpat kā klients to dara ar jūsu izvadi. Kad atskaņotājs ieraksta, piemēram, "north" un nospiež Enter, klients parasti nosūta šo virkni, kam seko rakstatgrieze un rindiņas padeve. Jūsu serveris nolasa līdz rindiņas beigām un interpretē to kā atskaņotāja komandu.
Ja klients nolemj uzsākt kādu opciju (piemēram, aktivizēt loga izmēra sarunas), jums ir jābūt gatavam saņemt IAC secības no klienta puses un atbilstoši reaģēt, nevis tikai otrādi.
8. Ko nosūta Telnet klients (ieskaitot mobilos klientus)
No jūsu servera viedokļa standarta Telnet klients (mobilais vai galddators) būtībā nosūtīs jums divu veidu lietas: lietotāja tekstu un Telnet komandas . Teksts parasti ir ASCII vai UTF-8 atkarībā no klienta; mūsdienās vislabāk ir pieņemt vismaz UTF-8.
Saņemtās Telnet komandas galvenokārt ir atbildes uz jūsu sarunu pieprasījumiem . Ja nosūtīsiet komandu `IAC DO GMCP`, klients atbildēs ar `IAC WILL GMCP`, ja tas to atbalsta, vai ar `IAC WONT GMCP`, ja tas to neatbalsta. Tas var arī pats uzsākt sarunas (piemēram, par termināļa tipu).
Svarīga mobilo ierīču saderības detaļa ir tā, ka daudzi mūsdienu klienti interpretē komandas rakstzīmi pa rakstzīmei vai rindiņu pa rindiņai atkarībā no konfigurācijas . Biežāk tiek izmantota šāda metode, tāpēc strukturējiet komandu ievades parsētāju, domājot par pilnām rindām, atdalītām ar \r\n, nevis atsevišķām rakstzīmēm.
9. Starpniekservera izmantošana un tīkla problēmas ar MUD ierobežotos tīklos
Dažās vidēs (piemēram, korporatīvajos tīklos, universitātes pilsētiņās vai noteiktu mobilo sakaru operatoru tīklos) MUD ierīču tipiskās augstās pieslēgvietas var būt bloķētas ar ugunsmūriem . Šādos gadījumos spēlētāji nevar tieši pieslēgties MUD ierīcei, pat ja Telnet ir atļauts standarta pieslēgvietās.
Klasisks risinājums ietver starpniekservera izmantošanu, kas klausās atļautā portā (piemēram, Telnet 23. portā vai FTP 21. portā) un pārsūta savienojumu uz MUD faktisko portu. Starpniekserveris darbojas kā tilts: klients izveido savienojumu ar starpniekserveri, un starpniekserveris nemanāmi atver savienojumu ar spēļu serveri.
Tāpat bieži kolēģis ar pastāvīgu interneta savienojumu savā datorā instalē starpniekserveri un ļauj citiem spēlētājiem piekļūt MUD, izmantojot savu IP adresi . Tomēr jābūt uzmanīgiem ar koplietotām IP adresēm: ja no vienas IP adreses pieslēdzas vairāki konti, daži MUD var to interpretēt kā neatļautu vairāku spēlētāju režīmu un piemērot sodus. Ideālā gadījumā jums vajadzētu paziņot spēles administratoriem, ja plānojat regulāri koplietot savu IP adresi.
10. MUD aizstājējvērtību ierobežojumi un riski
Lai gan starpniekserveris var ietaupīt jūsu drošību ļoti slēgtos tīklos, mūsdienās uzticamu publisku anonīmu starpniekservera pakalpojumu nav daudz , un tie daži, kas paliek, parasti ir pārslogoti, nedarbojas vai bloķēti drošības apsvērumu dēļ.
Turklāt tajos pašos tīklos, kas bloķē augstas pieslēgvietas, var būt bloķēta arī 8080. pieslēgvieta , kas ir ļoti izplatīta HTTP starpniekservera gadījumā. Tādēļ, ja kāds iestata privātu starpniekserveri, lai piekļūtu MUD, ieteicams to novietot pieslēgvietā, kas gandrīz nekad netiek filtrēta (23, 21 vai cita ļoti izplatīta un atļauta pieslēgvieta attiecīgajā tīklā).
Neaizmirstiet, ka šiem iestatījumiem ir drošības aspekti: datplūsma iet caur starpniekserveri, un sesijas, paroles utt. var tikt reģistrētas. No MUD servera dizaina viedokļa protokols nemainās, taču jums būs jāpieņem, ka daudzi savienojumi tiks "ietīti" caur starpniekserveri , kas potenciāli var izraisīt papildu latentumu vai biežākus savienojumu pārtraukšanas gadījumus.
11. Naratīvās mijiedarbības piemērs teksta MUD ietvaros
Papildus tehniskajiem aspektiem, uz tekstu balstīts MUD balstās uz bagātīgiem aprakstiem un atmosfēru . Daudzās spēlēs ir iekļauti ikoniski teksta fragmenti, literāri citāti vai gandrīz poētiski fragmenti, ko serveris burtiski nosūta klientam, lai uzlabotu spēlētāja iegremdēšanos.
Piemēram, ekrānā varētu parādīties sava veida "litānija pret bailēm", kad varonis saskaras ar izšķirošu brīdi. Tehniski tas nav nekas vairāk kā teksta rindiņu secība ar atbilstošiem pārtraukumiem un, ja nepieciešams, kādu krāsu vai formatējumu. Taču lietotāja pieredzes ziņā tam ir būtiska ietekme.
Šāda veida teksts, lai gan nemaina Telnet protokolu, ietekmē to, kā jūs apstrādājat rindstarpas, lappušu numerāciju un atsvaidzināšanas biežumu . Ja vienā piegājienā parādāt vairākas garas rindkopas, tās var kļūt nelasāmas mazos ekrānos (piemēram, mobilajos tālruņos). Tāpēc daudzi serveri ievieš "lappušu numerācijas" sistēmas, kas aptur izvadi pēc noteikta rindu skaita un gaida, kamēr spēlētājs nospiedīs taustiņu, lai turpinātu.
12. Ārējie resursi un papildu tehniskā dokumentācija
Atšķirībā no citiem ļoti standartizētiem protokoliem, MUD ekosistēmu ir veicinājuši izkliedēti dokumenti, akadēmiski PDF faili un brīvi raksti, kuros aprakstīti varianti, paplašinājumu priekšlikumi un pētījumi par mijiedarbību MUD vidēs.
Universitāšu krātuvēs un digitālajās bibliotēkās ir pieejami darbi, kuros analizēta MUD klienta-servera arhitektūra, evolūcija no vienkārša Telnet uz bagātinātiem protokoliem un pat lietotāja pieredzes problēmas teksta saskarnēs. Lai gan daudzi no šiem dokumentiem nemāca rindiņu pa rindiņai, kā formatēt ziņojumus, tie piedāvā noderīgu kontekstu, lai izprastu, kāpēc tika pieņemti noteikti protokoli un kā tie tiek apvienoti.
Lai papildinātu ieviešanu, ieteicams pārskatīt arī populāru MUD klientu (gan galddatoru, gan mobilo ierīču) dokumentāciju, kur parasti ir sīki aprakstīts, kādus paplašinājumus tie atbalsta (GMCP, MXP, MSDP utt.), kādas rakstzīmju kopas tie apstrādā, kā tie apstrādā ANSI krāsas un kādi ierobežojumi tiem ir mazos ekrānos.
13. Masveida domēni un resursdatora nosaukumi: infrastruktūras redzamais haoss
Ja kādreiz esat aplūkojis galveno mitināšanas pakalpojumu sniedzēju DNS ierakstus, iespējams, esat redzējis milzīgus sarakstus ar tādiem nosaukumiem kā www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test un neskaitāmas variācijas . Lai gan tas var šķist klusums, tas patiesībā atspoguļo to, kā ir organizēta infrastruktūra, kurā mitinās daudzi MUD un saistītie pakalpojumi.
Aiz viena domēna var atrast simtiem apakšdomēnu: datubāzes serverus, testēšanas iekārtas, starpniekservera serverus, slodzes līdzsvarotājus, statistikas pakalpojumus, e-pasta platformas, krātuves, VPN … un bieži vien pat portu, kurā klausās MUD. Dažos gadījumos spēle tiek spēlēta atsevišķā apakšdomēnā; citos tā koplieto IP adresi ar virkni pakalpojumu, sākot no forumiem līdz wiki un vadības paneļiem.
Šī nosaukumu daudzveidība ir būtiska, ja apsverat sava MUD publicēšanu koplietojamā serverī vai īpašu starpniekservera iestatīšanu spēlētājiem: jums būs rūpīgi jāsaskaņo, kuri apakšdomēni norāda uz kuru datoru, kuri porti tiek atvērti un kā tiek pārvaldīta drošība, lai Telnet datplūsma bīstami netraucētu citiem kritiski svarīgiem pakalpojumiem.
14. Praktiski apsvērumi Telnet klientiem mobilajās ierīcēs
Spēļu spēlēšana vai izstrāde ar Telnet klientu mobilajā ierīcē rada sarežģījumu slāni: mazs ekrāns, skārienjutīga tastatūra, iespējami bieži tīkla atvienojumi un dažreiz pašu klientu ierobežojumi paplašinājumu atbalsta ziņā.
Izstrādājot MUD serveri, ņemiet vērā dažus punktus:
- Izvairieties no pārāk garām rindām: labākas īsas rindkopas, lai lietotājam nebūtu jāritina no vienas puses uz otru.
- Mērena ANSI kodu lietošana Un pārliecinieties, ka tie neizjauc izkārtojumu klientiem, kuri tos labi neinterpretē.
- Rūpīgi rīkojieties ar lappušu numerāciju. lai pieredze nebūtu neiespējami izsekojama teksta siena.
- Ieviesiet mīkstu atkārtotu savienošanuMobilajā tālrunī ir viegli pazaudēt signālu un atjaunot savienojumu; jūsu serverim vajadzētu to pieļaut, nepārtraucot spēlētāja sesiju pie pirmā īsā pārtraukuma.
Daži mobilo ierīču klienti, kas specializējas MUD, jau ietver GMCP un citu paplašinājumu atbalstu, tāpēc, ja tos ieviešat serverī, varat piedāvāt strukturētu informāciju, ko klients attēlo kā paneļus, veselības joslas, ātrās kartes un citus vizuālos palīglīdzekļus klasiskā teksta vietā.
15. Izveidojiet savu MUD serveri, kas ir saderīgs ar esošajiem klientiem
Ja esat nolēmis rakstīt savu MUD serveri no nulles, izolācijas novēršanas atslēga ir respektēt Telnet kā bāzes slāni un pareizi vienoties par tā opcijām . Jums nav nepieciešams no jauna izgudrot protokolu, bet gan ievērot pārbaudītas konvencijas.
Īsāk sakot, lai nodrošinātu saderību ar visbiežāk izmantotajiem klientiem, jums vajadzētu:
- Īstenot Telnet komandu parsēšana (IAC, DO, DONT, WILL, WONT, SB, SE).
- Atbalstiet vismaz dažas izplatītas iespējas: atbalss, lokāla atbalss slāpēšana, GMCP Ja vēlaties bagātinātus datus un, iespējams, saspiešanu.
- Sūtīt teksts lietotājam draudzīgā formātāCRLF, ANSI pēc izvēles, nepārspīlējot ar garām līnijām.
- Pieņemt ievadi tiešsaistes režīmā un pareizi apstrādāt mobilo klientu nosūtītos rindiņu pārtraukumus.
No turienes jūs varat paplašināt savu serveri ar papildu protokoliem vai pat ar savu klientu, taču, sākot ar šo bāzi, jūs varat pārbaudīt savu spēli ar esošajiem Telnet klientiem un izmantot visu ekosistēmu, kas gadu gaitā ir izveidota ap MUD.
Visas šīs Telnet, paplašinājumi, starpniekserveri, resursdatora nosaukumi un mobilo klientu nianses sākumā var šķist mulsinošas, taču, ja visu soli pa solim sadalīsiet, redzēsiet, ka kodols ir diezgan vienkāršs: teksta plūsma ar dažām precīzi definētām vadības secībām. Izprotot, kā šie ziņojumi tiek veidoti, kā tiek saskaņotas opcijas un ko tipisks klients sagaida redzēt, jums būs nepieciešamie rīki, lai izveidotu stabilu, saderīgu un lietotājam draudzīgu MUD serveri, kam var piekļūt no jebkura Telnet klienta neatkarīgi no tā, vai tas atrodas mobilajā ierīcē vai galddatorā.