Protocollo e comunicazione nei giochi MUD testuali con Telnet

Se da un po' di tempo vi cimentate con i giochi MUD testuali e i client Telnet sul vostro dispositivo mobile , probabilmente vi sarete imbattuti nello stesso problema: tutti parlano della storia, della nostalgia e degli aneddoti legati a Telnet... ma quasi nessuno spiega chiaramente come client e server comunicano effettivamente. Questo articolo si propone di colmare questa lacuna: approfondire il protocollo, i messaggi, le sequenze di controllo e come far funzionare il vostro server MUD in modo impeccabile con i client esistenti.

Analizzeremo in modo approfondito e semplice il funzionamento di un tipico protocollo MUD basato su Telnet , le estensioni utilizzate nel settore (GMCP, MSSP, compressione, ecc.), la formattazione dei messaggi, le aspettative del client mobile e i dati da inviare dal server per garantire un funzionamento ottimale senza dover creare un protocollo da zero. Il tutto sarà spiegato in spagnolo standard (spagnolo), con esempi chiari e senza tecnicismi inutili.

1. Telnet come base: ciò che la maggior parte dei MUD utilizza effettivamente

La maggior parte dei MUD classici non inventa un nuovo protocollo di trasporto: si affidano a Telnet come livello di comunicazione tra client e server . Ciò significa che, in definitiva, ciò che viene inviato sono flussi di byte su TCP, dove il testo normale è mescolato con comandi Telnet speciali preceduti dal byte 255 (0xFF).

Dal punto di vista della rete, il server MUD si comporta come un server Telnet di base con una serie di estensioni opzionali . Il client (che sia un dispositivo mobile, un computer desktop o un semplice sistema Telnet) stabilisce una connessione TCP alla porta del MUD (spesso 23, 4000, 5000, ecc.) e da lì inizia un breve scambio di opzioni.

In questa fase iniziale di negoziazione, entrambe le parti si scambiano sequenze di controllo Telnet del tipo "WILL", "WONT", "DO" e "DONT" per attivare o disattivare funzionalità come eco, dimensione della finestra, protocolli aggiuntivi come GMCP, compressione, ecc. Tutto ciò viaggia mischiato al testo del gioco, ma il client è in grado di distinguerlo perché i comandi di controllo sono contrassegnati dal noto prefisso 0xFF.

2. Schema del protocollo Telnet utilizzato dai MUD

In Telnet, qualsiasi comando di controllo inizia con il byte IAC (Interpret As Command, valore 255) . A questo seguono uno o più byte che indicano il tipo di comando e, in molti casi, un codice opzione. Al livello standard del protocollo MUD, incontrerai principalmente:

• IAC DO"Voglio che tu (il cliente) attivi questa opzione."
• IAC NON"Non voglio che tu utilizzi questa opzione."
• IAC WILL: “Io (il server) posso e voglio utilizzare questa opzione.”
• IAC NON LO FARÀ"Non intendo utilizzare questa opzione."

Le opzioni sono identificate da un numero; alcune sono vecchi standard Telnet, altre sono estensioni concordate nella comunità MUD (ad esempio, GMCP, MSSP, COMPRESS2 ), che non compaiono nei classici RFC di Telnet, ma sono diventate di fatto uno "pseudo-standard" perché supportate dai principali client.

In qualità di MUD, in genere si avvia il dialogo inviando sequenze IAC DO/IAC WILL per verificare le funzionalità supportate dal client: se accetta GMCP, se desidera la compressione, se offre informazioni sul terminale, ecc. Il client risponderà con WILL/WONT o DO/DONT a seconda dei casi. Il server deve rispettare queste risposte e non utilizzare un'opzione se il client non la accetta.

3. Separazione tra testo di gioco e controllo Telnet

Una domanda frequente riguarda come distinguere il testo normale del gioco dai comandi di controllo . La regola è semplice: tutto ciò che non è preceduto da 0xFF è considerato testo. I comandi Telnet iniziano sempre con questo byte speciale, proprio per evitare confusione.

Esempio concettuale (non è necessario copiarlo alla lettera, serve solo per la visualizzazione): il server può inviare righe di descrizione dell'ambiente seguite da una sequenza IAC per negoziare un'opzione. Il client legge byte per byte: quando vede 0xFF, entra in "modalità comando"; per il resto del tempo lo tratta come testo, applica il colore ANSI se appropriato e lo visualizza.

Se mai doveste inviare un byte 0xFF come parte del testo (un'eventualità piuttosto rara, ma possibile), dovrete "escapearlo" duplicandolo . Ovvero, per inviare un 0xFF letterale nel flusso di dati a livello utente, dovrete inviare due 0xFF in successione e il client li interpreterà correttamente come "un singolo 0xFF di testo, non come un comando".

4. Formato del messaggio di testo: righe, interruzioni e colori

La maggior parte dei contenuti inviati dal tuo MUD consiste in messaggi di testo leggibili: descrizioni, finestre di dialogo, elenchi di oggetti e comandi . Sebbene possa sembrare banale, è importante prestare attenzione ad alcuni dettagli per garantire che i client Telnet (soprattutto su dispositivi mobili) li visualizzino correttamente.

In generale, i MUD utilizzano ancora lo stile classico di righe terminate con CRLF (\r\n) . Alcuni client supportano solo LF (\n), ma per la massima compatibilità, inviare sempre un ritorno a capo seguito da un avanzamento riga.

Per quanto riguarda il colore e la formattazione, i MUD utilizzano in genere codici di escape ANSI incorporati nel testo. Ad esempio, sequenze che iniziano con ESC (0x1B) seguite da "[31m" per il testo rosso, "[1m" per il grassetto, ecc. Questi non fanno parte del protocollo Telnet stesso, ma sono compresi dalla maggior parte dei terminali e dei client MUD avanzati, inclusi molti client per dispositivi mobili.

5. Estensioni MUD su Telnet: GMCP, MSSP e azienda

Oltre al testo semplice, molti MUD odierni combinano Telnet con protocolli aggiuntivi per scambiare dati strutturati con i client . Ciò consente ai client mobili di visualizzare interfacce più ricche rispetto a un semplice flusso di testo.

Tra le estensioni più frequenti figurano:

• GMCP (Protocollo di comunicazione MUD generico): invia informazioni in formato JSON (anche se non sempre standard al 100%) su personaggio, mappa, canali, ecc.
• MSSP (Protocollo di stato del server MUD): progettato per fornire dati del server (nome MUD, numero di giocatori, genere, ecc.) ai servizi di inserzione e ai clienti interessati.
• COMPRESS / COMPRESS2La compressione dei dati per ridurre la larghezza di banda è molto apprezzata nelle connessioni lente.

Queste estensioni vengono negoziate come qualsiasi altra opzione Telnet: il server in genere invia IAC WILL GMCP o IAC DO GMCP e attende la risposta. Una volta concordata, l'estensione stessa definisce come incapsulare i dati (ad esempio, GMCP viene utilizzato nelle sottonegoziazioni Telnet: IAC SB <opzione> … IAC SE).

6. Subnegoziazione (SB e SE): incapsulamento di dati speciali

Quando un'opzione Telnet richiede l'invio di più dati rispetto a un semplice sì/no, si ricorre alla subnegoziazione . Lo schema è il seguente:

• IAC SB IAC SE

All'interno di quel blocco, è possibile inviare stringhe, numeri o strutture specifiche definite dall'estensione . Ad esempio, GMCP in genere invia qualcosa di molto simile a un oggetto JSON, con virgolette, parentesi graffe e valori.

Quando il client riceve IAC SB GMCP, sa che tutto ciò che arriva fino a IAC SE fa parte del pacchetto GMCP e non del normale flusso di testo del gioco. Questo gli permette di separare chiaramente ciò che va all'interfaccia grafica da ciò che va al buffer di testo classico.

7. Cosa invia il server MUD: flusso di comunicazione tipico

Immaginate la sequenza che si verifica quando il giocatore si connette da un client Telnet mobile al vostro server MUD :

1. Il client apre una connessione TCP alla porta MUD.
2. Il server ti invia un banner di benvenuto (testo) e probabilmente anche qualcosa Sequenze IAC per il trading di opzioni (eco, GMCP, compressione…).
3. Il cliente risponde accettando o rifiutando tali opzioni con WILL/WONT e DO/DONT.
4. Da lì, il server invia la schermata di accesso (testo) ed elabora i comandi digitati dal giocatore.

In ogni momento, il server deve essere in grado di leggere l'input del client come una combinazione di testo e comandi Telnet , proprio come il client fa con il tuo output. Quando il giocatore digita, ad esempio, "north" e preme Invio, il client in genere invia quella stringa seguita da un ritorno a capo e un avanzamento riga. Il tuo server legge fino alla fine della riga e la interpreta come un comando del giocatore.

Se il client decide di avviare una qualsiasi opzione (ad esempio, innescando una negoziazione della dimensione della finestra), è necessario essere pronti a ricevere sequenze IAC dal lato client e a rispondere in modo appropriato, e non solo viceversa.

8. Cosa invia il client Telnet (inclusi i client mobili)

Dal punto di vista del server, un client Telnet standard (mobile o desktop) invierà fondamentalmente due tipi di dati: testo utente e comandi Telnet . Il testo è solitamente in formato ASCII o UTF-8 a seconda del client; oggigiorno è consigliabile presumere almeno che sia in UTF-8.

I comandi Telnet che ricevi sono principalmente risposte alle tue richieste di negoziazione . Se invii `IAC DO GMCP`, il client risponderà con `IAC WILL GMCP` se lo supporta, oppure con `IAC WONT GMCP` in caso contrario. Può anche avviare autonomamente alcune negoziazioni (ad esempio, relative al tipo di terminale).

Un dettaglio importante per la compatibilità con i dispositivi mobili è che molti client moderni interpretano i comandi carattere per carattere o riga per riga, a seconda della configurazione . L'interpretazione riga per riga è più comune, quindi struttura il tuo parser di input dei comandi pensando in termini di righe complete separate da \r\n, non di singoli caratteri.

9. Utilizzo di proxy e problemi di rete con i MUD in reti con restrizioni

In alcuni ambienti (ad esempio, reti aziendali, campus o determinati operatori di telefonia mobile), le porte ad alto numero di porte tipicamente utilizzate dai MUD potrebbero essere bloccate dai firewall . In questi casi, i giocatori scoprono di non potersi connettere direttamente alla porta del MUD, anche se Telnet è consentito sulle porte standard.

Una soluzione classica prevede l'utilizzo di un proxy intermedio che rimane in ascolto su una porta consentita (come la porta Telnet 23 o la porta FTP 21) e inoltra la connessione alla porta effettiva del MUD. Il proxy funge da ponte: il client si connette al proxy e quest'ultimo, in background, apre la connessione al server di gioco.

È anche comune che un collega con una connessione internet permanente installi un proxy sul proprio computer e permetta ad altri giocatori di accedere al MUD tramite il suo indirizzo IP . Tuttavia, è necessario prestare attenzione agli IP condivisi: se più account si connettono dallo stesso IP, alcuni MUD potrebbero interpretarlo come multiplayer illegale e infliggere delle penalità. Idealmente, dovresti avvisare gli amministratori del gioco se intendi condividere regolarmente il tuo indirizzo IP.

10. Limitazioni e rischi dei proxy per MUD

Sebbene un proxy possa essere utile in reti molto chiuse, al giorno d'oggi i proxy pubblici anonimi affidabili non sono numerosi e i pochi rimasti sono solitamente sovraccarichi, non funzionanti o bloccati per motivi di sicurezza.

Inoltre, le stesse reti che bloccano le porte alte potrebbero bloccare anche la porta 8080 , una situazione molto comune per i proxy HTTP. Pertanto, se qualcuno configura un proxy privato per accedere a un MUD, è consigliabile impostarlo su una porta che non viene quasi mai filtrata (23, 21 o un'altra porta comune e consentita sulla rete in questione).

Non dimenticate che queste configurazioni hanno implicazioni per la sicurezza: il traffico passa attraverso una macchina intermedia e sessioni, password, ecc., possono essere registrate. Dal punto di vista della progettazione di un server MUD, il protocollo non cambia, ma dovrete presumere che molte connessioni saranno "instradate" attraverso un proxy , con conseguente potenziale aumento della latenza o disconnessioni più frequenti.

11. Esempio di interazione narrativa all'interno di un MUD testuale

Al di là degli aspetti tecnici, un MUD testuale si basa su descrizioni dettagliate e un'atmosfera coinvolgente . Molti giochi includono frammenti di testo iconici, citazioni letterarie o passaggi quasi poetici che il server invia letteralmente al client per migliorare l'immersione del giocatore.

Ad esempio, una sorta di "litania contro la paura" potrebbe apparire sullo schermo quando il personaggio si trova ad affrontare un momento cruciale. Tecnicamente, non è altro che una sequenza di righe di testo con le opportune interruzioni e, se lo si desidera, con l'aggiunta di colore o formattazione. Ma in termini di esperienza utente, ha un impatto significativo.

Questo tipo di testo, pur non modificando il protocollo Telnet, influisce sulla gestione dell'interlinea, della paginazione e della frequenza di aggiornamento . Se si visualizzano diversi paragrafi lunghi in un'unica sequenza, il testo può risultare illeggibile su schermi di piccole dimensioni (come quelli dei telefoni cellulari). Per questo motivo, molti server implementano sistemi di "paginazione" che mettono in pausa l'output dopo un certo numero di righe e attendono che il lettore prema un tasto per continuare.

12. Risorse esterne e documentazione tecnica aggiuntiva

A differenza di altri protocolli altamente standardizzati, l'ecosistema MUD si è sviluppato attraverso documenti sparsi, PDF accademici e articoli indipendenti che descrivono varianti, proposte di estensione e studi sull'interazione negli ambienti MUD.

Nei repository universitari e nelle biblioteche digitali sono disponibili opere che analizzano l'architettura client-server dei MUD, l'evoluzione dal semplice Telnet ai protocolli più complessi e persino le problematiche relative all'esperienza utente nelle interfacce testuali. Sebbene molti di questi documenti non spieghino nel dettaglio come formattare i messaggi, offrono un contesto utile per comprendere perché determinati protocolli sono stati adottati e come vengono combinati.

A complemento dell'implementazione, è consigliabile consultare anche la documentazione dei client MUD più diffusi (sia per desktop che per dispositivi mobili), dove solitamente vengono specificate le estensioni supportate (GMCP, MXP, MSDP, ecc.), i set di caratteri gestiti, il modo in cui gestiscono i colori ANSI e le limitazioni presenti sugli schermi di piccole dimensioni.

13. Domini e nomi host enormi: il caos visibile dell'infrastruttura

Se avete mai dato un'occhiata ai record DNS dei principali provider di hosting, probabilmente avrete visto lunghissimi elenchi di nomi come www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test e innumerevoli varianti . Sebbene possa sembrare un caos, in realtà questo riflette il modo in cui è organizzata l'infrastruttura che ospita molti MUD e servizi correlati.

Dietro un singolo dominio si celano centinaia di sottodomini: server di database, macchine di test, proxy, bilanciatori di carico, servizi di statistiche, piattaforme di posta elettronica, storage, VPN … e spesso persino la porta su cui è in ascolto un MUD. In alcuni casi, il gioco si svolge su un sottodominio dedicato; in altri, condivide un indirizzo IP con un groviglio di servizi che spaziano dai forum ai wiki e ai pannelli di controllo.

Questa proliferazione di nomi è rilevante se si intende pubblicare il proprio MUD su un server condiviso o configurare proxy specifici per i giocatori: sarà necessario coordinare attentamente quali sottodomini puntano a quale macchina, quali porte sono aperte e come viene gestita la sicurezza in modo che il traffico Telnet non interferisca pericolosamente con altri servizi critici.

14. Considerazioni pratiche per i clienti Telnet su dispositivi mobili

Giocare o sviluppare con un client Telnet su un dispositivo mobile aggiunge un ulteriore livello di complessità: schermo piccolo, tastiera virtuale, possibili frequenti disconnessioni di rete e, a volte, limitazioni dei client stessi in termini di supporto per le estensioni.

Quando progettate il vostro server MUD, tenete a mente alcuni punti:

• Evitate le file eccessivamente lunghe: paragrafi più brevi per evitare che l'utente debba scorrere orizzontalmente.
• Moderare l'uso dei codici ANSI E assicuratevi che non modifichino il layout per i clienti che non lo interpretano correttamente.
• Gestire la paginazione con attenzione. in modo che l'esperienza non si trasformi in un muro di testo impossibile da seguire.
• Implementare riconnessioni softSui dispositivi mobili è facile perdere il segnale e riconnettersi; il server dovrebbe tollerare questa situazione senza interrompere la sessione del giocatore alla prima breve interruzione.

Alcuni client per dispositivi mobili specializzati in MUD integrano già il supporto per GMCP e altre estensioni, quindi implementandole sul server è possibile offrire informazioni strutturate che il client visualizza come pannelli, barre della salute, mappe rapide e altri ausili visivi al posto del testo classico.

15. Crea il tuo server MUD compatibile con i client esistenti

Se hai deciso di scrivere il tuo server MUD da zero, la chiave per evitare l'isolamento è rispettare Telnet come livello base e negoziare correttamente le sue opzioni . Non è necessario reinventare il protocollo, ma piuttosto seguire le convenzioni collaudate.

In breve, per essere compatibile con i client più comuni dovresti:

• Strumento Analisi dei comandi Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
• Sostieni almeno alcune delle opzioni più comuni: eco, soppressione dell'eco locale, GMCP Se desideri dati arricchiti e, eventualmente, compressi.
• Invia testo in formato di facile utilizzoCRLF, ANSI opzionale, senza utilizzare eccessivamente linee di grandi dimensioni.
• Accetta input in modalità online e gestisci correttamente le interruzioni di riga inviate dai client mobili.

Da lì è possibile estendere il server con protocolli aggiuntivi o persino con un client personalizzato, ma partire da questa base permette di testare il gioco con client Telnet esistenti e di sfruttare l'intero ecosistema che si è creato attorno ai MUD nel corso degli anni.

Tutto questo Telnet, estensioni, proxy, nomi host e peculiarità dei client mobili potrebbe sembrare inizialmente complicato, ma se lo si analizza passo dopo passo, si scoprirà che il nucleo è piuttosto semplice: un flusso di testo con alcune sequenze di controllo ben definite. Comprendendo come vengono formati questi messaggi, come vengono negoziate le opzioni e cosa si aspetta di vedere un client tipico, si avranno gli strumenti necessari per creare un server MUD robusto, compatibile e intuitivo, accessibile da qualsiasi client Telnet, sia su dispositivo mobile che su computer desktop.