Protocolo e comunicação em jogos MUD baseados em texto com Telnet

Se você já mexeu com jogos MUD baseados em texto e clientes Telnet em seu dispositivo móvel por algum tempo , provavelmente já se deparou com o mesmo problema: todo mundo fala sobre a história, a nostalgia e as anedotas do Telnet… mas quase ninguém explica claramente como o cliente e o servidor realmente se comunicam. Este artigo visa preencher essa lacuna: aprofundar-se no protocolo, nas mensagens, nas sequências de controle e em como fazer seu próprio servidor MUD funcionar perfeitamente com clientes existentes.

Vamos analisar de forma completa e direta como funciona um protocolo MUD típico baseado em Telnet , quais extensões são usadas no setor (GMCP, MSSP, compressão, etc.), como as mensagens são formatadas, o que o cliente móvel espera receber e o que você precisa enviar do seu servidor para garantir que tudo funcione perfeitamente, sem precisar criar um protocolo do zero. Tudo isso será explicado em espanhol padrão (da Espanha), com exemplos claros e sem jargões desnecessários.

1. Telnet como base: o que a maioria dos MUDs realmente usa

A maioria dos MUDs clássicos não inventa um novo meio de transporte: eles dependem do Telnet como camada de comunicação entre o cliente e o servidor . Isso significa que, no final das contas, o que é enviado são fluxos de bytes via TCP, onde o texto normal é misturado com comandos especiais do Telnet precedidos pelo byte 255 (0xFF).

Do ponto de vista da rede, o servidor MUD se comporta como um servidor Telnet básico com uma série de extensões opcionais . O cliente (seja ele um dispositivo móvel, um computador ou um sistema Telnet simples) estabelece uma conexão TCP com a porta do MUD (geralmente 23, 4000, 5000, etc.) e, a partir daí, inicia-se uma breve troca de opções.

Nessa negociação inicial, ambas as partes enviam uma à outra sequências de controle Telnet do tipo "WILL", "WONT", "DO" e "DONT" para ativar ou desativar recursos: eco, tamanho da janela, protocolos adicionais como GMCP, compressão, etc. Tudo isso é transmitido misturado ao texto do jogo, mas o cliente consegue distinguir porque os comandos de controle são marcados com o conhecido prefixo 0xFF.

2. Esqueleto do protocolo Telnet usado pelos MUDs

Em Telnet, qualquer comando de controle começa com o byte IAC (Interpret As Command, valor 255) . Este é seguido por um ou mais bytes que indicam o tipo de comando e, em muitos casos, um código de opção. No nível do protocolo MUD padrão, você encontrará principalmente:

IAC DO"Quero que você (o cliente) ative esta opção."
IAC NÃO"Não quero que você use essa opção."
IAC“Eu (o servidor) posso e quero usar esta opção.”
IAC NÃO"Não vou usar essa opção."

As opções são identificadas por um número; algumas são padrões antigos do Telnet, outras são extensões acordadas na comunidade MUD (por exemplo, GMCP, MSSP, COMPRESS2 ), que não aparecem nos RFCs clássicos do Telnet, mas se tornaram um "pseudo-padrão" de facto porque os principais clientes as suportam.

Como um MUD, você normalmente inicia o diálogo enviando sequências IAC DO/IAC WILL para testar o que o cliente suporta: se aceita GMCP, se deseja compressão, se oferece informações de terminal, etc. O cliente responderá com WILL/WONT ou DO/DONT, conforme apropriado. Seu servidor deve respeitar essas respostas e não usar uma opção se o cliente não a aceitar.

3. Separação entre o texto do jogo e o controle Telnet

Uma dúvida comum é como distinguir entre o texto normal do jogo e os comandos de controle . A regra é simples: tudo que não for precedido por 0xFF é considerado texto. Os comandos Telnet sempre começam com esse byte especial, justamente para evitar confusão.

Exemplo conceitual (não precisa copiar literalmente, é apenas para visualização): o servidor pode enviar linhas de descrição do ambiente seguidas por uma sequência IAC para negociar uma opção. O cliente lê byte a byte: quando encontra 0xFF, entra no "modo de comando"; no restante do tempo, trata como texto, aplica a cor ANSI, se apropriado, e exibe.

Se você precisar enviar um byte 0xFF como parte do texto (algo raro, mas possível), você deve "escapar" dele duplicando-o . Ou seja, para enviar um 0xFF literal no fluxo de dados do espaço do usuário, você envia dois 0xFFs em sequência, e o cliente os interpreta corretamente como "um único 0xFF de texto, não um comando".

4. Formato da mensagem de texto: linhas, quebras e cores

A maior parte do conteúdo que seu MUD enviará consiste em mensagens de texto legíveis: descrições, diálogos, listas de objetos e comandos . Embora isso possa parecer trivial, vale a pena prestar atenção a alguns detalhes para garantir que os clientes Telnet (especialmente em dispositivos móveis) o exibam corretamente.

Em geral, os MUDs ainda usam o estilo clássico de linhas terminadas com CRLF (\r\n) . Alguns clientes suportam apenas LF (\n), mas para máxima compatibilidade, sempre envie um retorno de carro seguido por uma alimentação de linha.

Para cores e formatação, os MUDs normalmente usam códigos de escape ANSI incorporados no texto. Por exemplo, sequências que começam com ESC (0x1B) seguidas por “[31m” para texto vermelho, “[1m” para negrito, etc. Esses códigos não fazem parte do protocolo Telnet em si, mas são compreendidos pela maioria dos terminais e clientes MUD avançados, incluindo muitos clientes móveis.

5. Extensões MUD sobre Telnet: GMCP, MSSP e outras empresas

Além de texto simples, muitos MUDs atuais combinam Telnet com protocolos adicionais para trocar dados estruturados com os clientes . Isso permite que os clientes móveis exibam interfaces mais ricas do que um simples fluxo de texto.

Entre as extensões mais frequentes estão:

GMCP (Protocolo Genérico de Comunicação MUD): envia informações em formato JSON (embora nem sempre 100% padronizado) sobre personagens, mapas, canais, etc.
MSSP (Protocolo de Status do Servidor Mud): Projetado para fornecer dados do servidor (nome do MUD, número de jogadores, gênero, etc.) para serviços de listagem e clientes curiosos.
COMPRESSÃO / COMPRESSÃO2Compressão de dados para reduzir o consumo de banda, algo muito valioso em conexões lentas.

Essas extensões são negociadas da mesma forma que qualquer outra opção do Telnet: o servidor normalmente envia IAC WILL GMCP ou IAC DO GMCP e aguarda a resposta. Uma vez acordada, a própria extensão define como encapsular os dados (por exemplo, GMCP entra em subnegociações do Telnet: IAC SB <opção> … IAC SE).

6. Subnegociação (SB e SE): encapsulamento de dados especiais

Quando uma opção do Telnet exige o envio de mais dados do que um simples sim/não, utiliza-se a subnegociação . O padrão é:

IAC SB IAC SE

Dentro desse bloco, você pode enviar strings, números ou estruturas específicas definidas pela extensão . Por exemplo, o GMCP normalmente envia algo muito semelhante a um objeto JSON, com aspas, chaves e valores.

Quando o cliente recebe o IAC SB GMCP, ele sabe que tudo até o IAC SE faz parte do pacote GMCP, e não do fluxo de texto normal do jogo. Isso permite separar claramente o que vai para a interface gráfica do que vai para o buffer de texto clássico.

7. O que o servidor MUD envia: fluxo de comunicação típico

Imagine a sequência de eventos desde o momento em que o jogador se conecta de um cliente Telnet móvel ao seu servidor MUD :

O cliente abre uma conexão TCP com a porta MUD.
O servidor envia um banner de boas-vindas (texto) e provavelmente algumas outras mensagens. Sequências IAC para negociação de opções (eco, GMCP, compressão…).
O cliente responde aceitando ou rejeitando essas opções com WILL/WONT e DO/DONT.
A partir daí, o servidor envia a tela de login (texto) e processa os comandos que o jogador digita.

O servidor deve ser capaz de ler a entrada do cliente como uma combinação de texto e comandos Telnet em todos os momentos , assim como o cliente faz com a sua saída. Quando o jogador digita, por exemplo, "norte" e pressiona Enter, o cliente normalmente envia essa string seguida por um retorno de carro e uma quebra de linha. Seu servidor lê até o final da linha e a interpreta como um comando do jogador.

Se o cliente decidir iniciar alguma opção (por exemplo, acionar uma negociação de tamanho de janela), você também deve estar preparado para receber sequências IAC do lado do cliente e responder adequadamente, e não apenas o contrário.

8. O que o cliente Telnet envia (incluindo clientes móveis)

Do ponto de vista do seu servidor, um cliente Telnet padrão (móvel ou desktop) enviará basicamente dois tipos de dados: texto do usuário e comandos Telnet . O texto geralmente é ASCII ou UTF-8, dependendo do cliente; atualmente, é melhor assumir pelo menos UTF-8.

Os comandos Telnet que você recebe são principalmente respostas às suas solicitações de negociação . Se você enviar `IAC DO GMCP`, o cliente responderá com `IAC WILL GMCP` se suportar o protocolo, ou com `IAC WONT GMCP` caso contrário. Ele também pode iniciar alguma negociação por conta própria (por exemplo, em relação ao tipo de terminal).

Um detalhe importante para a compatibilidade com dispositivos móveis é que muitos clientes modernos interpretam os comandos caractere por caractere ou linha por linha, dependendo da configuração . A interpretação linha por linha é mais comum, portanto, estruture seu analisador de entrada de comandos pensando em termos de linhas completas separadas por \r\n, e não em caracteres individuais.

9. Utilização de proxies e problemas de rede com MUDs em redes restritas

Em alguns ambientes (por exemplo, redes corporativas, campi universitários ou certas operadoras de telefonia móvel), as portas padrão normalmente usadas por MUDs podem ser bloqueadas por firewalls . Nesses casos, os jogadores descobrem que não conseguem se conectar diretamente à porta do MUD, mesmo que o Telnet seja permitido em portas padrão.

Uma solução clássica envolve o uso de um proxy intermediário que escuta em uma porta permitida (como a porta 23 do Telnet ou a porta 21 do FTP) e encaminha a conexão para a porta real do MUD. O proxy atua como uma ponte: o cliente se conecta ao proxy e o proxy, nos bastidores, abre a conexão com o servidor do jogo.

Também é comum que um colega com conexão permanente à internet instale um proxy em seu computador e permita que outros jogadores acessem o MUD através de seu endereço IP . No entanto, é preciso ter cuidado com IPs compartilhados: se várias contas se conectarem a partir do mesmo IP, alguns MUDs podem interpretar isso como multiplayer ilegal e aplicar penalidades. O ideal é notificar os administradores do jogo se você planeja compartilhar seu endereço IP regularmente.

10. Limitações e riscos de proxies para MUD

Embora um proxy possa ser útil em redes muito fechadas, atualmente proxies públicos anônimos confiáveis são raros , e os poucos que restam geralmente estão sobrecarregados, fora do ar ou bloqueados por motivos de segurança.

Além disso, as mesmas redes que bloqueiam portas altas também podem bloquear a porta 8080 , o que é muito comum para proxies HTTP. Portanto, se alguém configurar um proxy privado para acessar um MUD, é recomendável colocá-lo em uma porta que quase nunca seja filtrada (23, 21 ou outra porta muito comum e permitida na rede em questão).

Use seu celular como servidor FTP para transferências rápidas.

11. Exemplo de interação narrativa dentro de um texto MUD

Além dos aspectos técnicos, um MUD baseado em texto depende de descrições ricas e atmosfera envolvente . Muitos jogos incluem trechos de texto icônicos, citações literárias ou fragmentos quase poéticos que o servidor envia literalmente para o cliente para aprimorar a imersão do jogador.

Por exemplo, uma espécie de "ladainha contra o medo" pode aparecer na tela quando o personagem enfrenta um momento crucial. Tecnicamente, trata-se apenas de uma sequência de linhas de texto com quebras apropriadas e, se desejado, alguma cor ou formatação. Mas, em termos de experiência do usuário, o impacto é significativo.

Esse tipo de texto, embora não altere o protocolo Telnet, afeta a forma como você lida com o espaçamento entre linhas, a paginação e as taxas de atualização . Se você exibir vários parágrafos longos de uma só vez, eles podem se tornar ilegíveis em telas pequenas (como as de celulares). É por isso que muitos servidores implementam sistemas de "paginação" que pausam a saída após um certo número de linhas e aguardam que o usuário pressione uma tecla para continuar.

12. Recursos externos e documentação técnica adicional

Ao contrário de outros protocolos altamente padronizados, o ecossistema MUD tem sido impulsionado por documentos dispersos, PDFs acadêmicos e artigos soltos que descrevem variantes, propostas de extensão e estudos sobre interação em ambientes MUD.

Existem trabalhos disponíveis em repositórios universitários e bibliotecas digitais que analisam a arquitetura cliente-servidor de MUDs, a evolução do Telnet básico para protocolos complexos e até mesmo questões de experiência do usuário em interfaces de texto. Embora muitos desses documentos não ensinem linha por linha como formatar mensagens, eles oferecem um contexto útil para entender por que certos protocolos foram adotados e como são combinados.

Para complementar a implementação, também é aconselhável consultar a documentação de clientes MUD populares (tanto para desktop quanto para dispositivos móveis), onde geralmente detalham quais extensões são suportadas (GMCP, MXP, MSDP, etc.), quais conjuntos de caracteres são compatíveis, como lidam com cores ANSI e quais limitações apresentam em telas pequenas.

13. Domínios e nomes de host massivos: o caos visível da infraestrutura

Se você já examinou os registros DNS dos principais provedores de hospedagem, provavelmente viu listas enormes de nomes como www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test e inúmeras variações . Embora possa parecer ruído, isso na verdade reflete como a infraestrutura que hospeda muitos MUDs e serviços relacionados está organizada.

Por trás de um único domínio, podem ser encontrados centenas de subdomínios: servidores de banco de dados, máquinas de teste, proxies, balanceadores de carga, serviços de estatísticas, plataformas de e-mail, armazenamento, VPNs … e, frequentemente, até mesmo a porta onde um MUD está em execução. Em alguns casos, o jogo é executado em um subdomínio discreto; em outros, compartilha um endereço IP com uma complexa rede de serviços, que vão de fóruns a wikis e painéis de controle.

Essa proliferação de nomes é relevante se você estiver pensando em publicar seu MUD em um servidor compartilhado ou configurar proxies específicos para os jogadores: você precisará coordenar cuidadosamente quais subdomínios apontam para qual máquina, quais portas estão abertas e como a segurança é gerenciada para que o tráfego Telnet não interfira perigosamente em outros serviços críticos.

14. Considerações práticas para clientes Telnet em dispositivos móveis

Jogar ou desenvolver com um cliente Telnet em um dispositivo móvel adiciona uma camada de complicação: tela pequena, teclado virtual, possíveis desconexões frequentes da rede e, às vezes, limitações dos próprios clientes em termos de suporte a extensões.

Ao projetar seu servidor MUD, tenha em mente alguns pontos:

Evite filas excessivamente longas.Parágrafos mais curtos para que o usuário não precise rolar a página de um lado para o outro.
Modere o uso dos códigos ANSI. E certifique-se de que eles não comprometam o layout para clientes que não os interpretam bem.
Gerencie a paginação com cuidado. para que a experiência não seja um bloco de texto impossível de acompanhar.
Implementar reconexões suavesEm dispositivos móveis, é fácil perder o sinal e reconectar; seu servidor deve tolerar isso sem interromper a sessão do jogador na primeira breve interrupção.

Alguns clientes móveis especializados em MUDs já incorporam suporte para GMCP e outras extensões, portanto, se você as implementar no servidor, poderá oferecer informações estruturadas que o cliente exibe como painéis, barras de vida, mapas rápidos e outros recursos visuais sobre o texto clássico.

15. Crie seu próprio servidor MUD compatível com clientes existentes.

Se você decidiu escrever seu próprio servidor MUD do zero, a chave para evitar o isolamento é respeitar o Telnet como camada base e negociar suas opções corretamente . Você não precisa reinventar o protocolo, mas sim seguir as convenções comprovadas.

Resumindo, para ser compatível com os clientes mais comuns, você deve:

Implemento Análise de comandos Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
Apoie pelo menos algumas opções comuns: eco, supressão de eco local, GMCP Se você deseja dados enriquecidos e, possivelmente, compressão.
Enviar texto em formato amigável ao usuárioCRLF, ANSI opcional, sem usar linhas muito grandes.
Aceitar entradas no modo online e lidar corretamente com quebras de linha enviadas por clientes móveis.

A partir daí, você pode expandir seu servidor com protocolos adicionais ou até mesmo com seu próprio cliente, mas começar com essa base permite testar seu jogo com clientes Telnet existentes e aproveitar todo o ecossistema que foi criado em torno dos MUDs ao longo dos anos.