Waterfall Minecraft Proxy: Arquitetura, Funcionalidades e Le

Waterfall é um fork de BungeeCord que não é mais mantido. Antes de instalá-lo, você deve saber: os mantenedores recomendam mudar para Velocity em seu lugar. Dito isso, entender o design do Waterfall e por que ele existiu ensina algo real sobre como grandes redes Minecraft funcionam. Se você está gerenciando uma configuração de proxy ou desenvolvendo plugins de servidor, ainda há valor em saber o que Waterfall estava tentando resolver.

O Que Era Waterfall

BungeeCord é o padrão da indústria para conectar múltiplos servidores Minecraft. Um único servidor proxy fica na frente de seus servidores de jogo reais e roteia os jogadores entre eles. Mas a base de código do BungeeCord não foi projetada para a escala que alguns admins precisavam. Waterfall era um fork criado pela equipe do PaperMC (o mesmo grupo por trás do Paper, o software de servidor imensamente popular) para construir um proxy que não sacrificasse desempenho por estabilidade.

O projeto se focou em três coisas:

• Estabilidade - código que é testável e não fica lento sob carga
• Funcionalidades - mais funcionalidades que o BungeeCord canônico, adicionadas mais rápido
• Escalabilidade - manipulação de milhares de jogadores simultâneos em hardware moderno

Parece simples agora, mas na época, os mantenedores do BungeeCord original não estavam aceitando contribuições no ritmo que a comunidade queria. Waterfall existia porque o fork era mais rápido e mais disposto a experimentar.

Por Que o Fork Aconteceu (E O Que Isso Diz Sobre Open Source)

Esta é a parte interessante. BungeeCord é open source, mas se move cautelosamente. Os mantenedores do Waterfall basicamente disseram: "Podemos fazer isso mais rápido." Eles fizeram fork do projeto, continuaram mesclando mudanças do upstream, mas também adicionaram seus próprios patches. Isso os permitiu entregar funcionalidades e correções enquanto ainda acompanhavam as atualizações do núcleo do BungeeCord.

Não era hostil ou contencioso. Era pragmático.

A comunidade de admins de servidor Minecraft tinha problemas reais de escalabilidade, e o fork permitiu que eles os resolvessem sem esperar consenso do upstream. É assim que o open source realmente funciona às vezes - nem todos esperando permissão.

Como Waterfall Funcionava Sob o Capô

Como o BungeeCord, Waterfall ficava entre os jogadores e seus servidores backend. Quando um jogador se conecta, Waterfall lida com o login e decide para qual servidor roteá-lo. Gerencia mudanças de servidor, chat, movimento e toda a lógica do proxy. A diferença estava nos detalhes: melhor desempenho sob carga simultânea, estrutura de código mais limpa e uma API mais ativa.

Para desenvolvedores de plugins, Waterfall fornecia uma API de JavaDocs limpa e artefatos Maven/Gradle. Você pode construir plugins usando:

<repository>
 <id>papermc</id>
 <url>https://repo.papermc.io/repository/maven-public/</url>
</repository>

<dependency>
 <groupId>io.github.waterfallmc</groupId>
 <artifactId>waterfall-api</artifactId>
 <version>1.21-R0.3-SNAPSHOT</version>
 <scope>provided</scope>
</dependency>

Ou com Gradle:

repositories {
 maven {
 url 'https://repo.papermc.io/repository/maven-public/'
 }
}

dependencies {
 compileOnly 'io.github.waterfallmc:waterfall-api:1.21-R0.3-SNAPSHOT'
}

Esta API era um dos pontos fortes do Waterfall - era ativamente documentada e mantida em sincronismo com as versões, diferentemente de alguns projetos proxy onde a documentação da API fica atrás do código.

Instalação e Compilação

Executar Waterfall exigia Java 8 ou superior (bem padrão). Você baixaria o arquivo JAR de papermc.io/downloads, o colocaria em uma pasta e o executaria. A configuração era um YAML simples.

Se você quisesse compilar a partir da fonte, Waterfall mantinha a compilação simples:

git clone https://github.com/PaperMC/Waterfall.git
cd Waterfall./waterfall b

Esse comando lidava com a extração de dependências, execução de testes e compilação do JAR. O binário compilado acabava em Waterfall-Proxy/bootstrap/target/. Limpo. Sem cerimônia desnecessária.

O Que Diferenciava Waterfall do BungeeCord Simples

Desempenho não era apenas marketing. Os patches do Waterfall focavam em reduzir a sobrecarga do proxy. Alguns destaques:

• Melhor manipulação de conexões simultâneas de jogadores sem gargalos de pool de threads
• Gerenciamento de buffer mais inteligente para reduzir pausas de coleta de lixo
• Manipulação de pacotes mais eficiente, especialmente para grandes contagens de jogadores
• Código testável - os mantenedores realmente escreveram testes unitários, o que o BungeeCord nem sempre priorizava

Se você estava executando uma rede com 5.000+ jogadores simultâneos, isso importava. Se você tivesse 200 jogadores, você não notaria muita diferença.

O projeto também respondia mais rápido a problemas de segurança e atualizações de compatibilidade quando novas versões do Minecraft saíam. PaperMC tinha recursos e motivação para se mover rapidamente.

Por Que Waterfall Foi Arquivado

PaperMC não abandonou Waterfall levianamente. Eles criaram algo melhor: Velocity. Velocity não é um fork do BungeeCord - é um proxy completamente novo escrito do zero. Ele é projetado para Java moderno, tem melhor desempenho, APIs de plugin mais limpas e desenvolvimento mais ativo.

Os mantenedores do Waterfall fizeram um anúncio oficial: use Velocity em seu lugar. Eles estão mantendo, melhorando e é para onde o ecossistema de proxy do servidor Minecraft está indo. Depois de um período em que ambos os projetos existiam, eles decidiram colocar Waterfall no modo de arquivo.

Isso não era uma falha. Era os autores reconhecendo que a próxima geração de seu próprio software era melhor e sendo honestos com a comunidade sobre isso.

O Que Isso Significa Para Sua Configuração de Servidor

Se você está construindo uma nova rede de proxy hoje, não use Waterfall. Use Velocity. É mantido ativamente, funciona melhor e você receberá correções de bugs e atualizações de segurança.

Se você está curioso sobre como os proxies Minecraft funcionam em um nível mais profundo, a base de código e arquitetura do Waterfall ainda têm valor educacional. Ler os patches e entender por que eram necessários ensina coisas reais sobre desempenho do proxy.

E se você já está executando Waterfall em uma rede estável? A migração para Velocity é direta e a equipe do PaperMC fornece orientação para isso. Os formatos de configuração são diferentes, mas não drasticamente.

Uma dica prática: se você está personalizando sua lista de servidor com texto MOTD (a mensagem que aparece quando os jogadores veem seu servidor no menu multijogador), ferramentas como nosso Criador de MOTD podem ajudá-lo a formatar isso adequadamente para seu proxy. Waterfall e Velocity respeitam a formatação MOTD padrão.

Aprendendo com a História do Waterfall

Waterfall importa não porque você deva usá-lo hoje, mas porque representa algo importante no open source. Uma equipe reconheceu um problema real, fez fork de um projeto, provou que podia resolvê-lo melhor e depois fez a transição graciosamente para um sucessor quando a próxima evolução ficou clara.

Não morreu porque era ruim. Mas teve tanto sucesso que seus criadores construíram algo melhor para substituí-lo e tiveram a integridade de dizer às pessoas para usar aquilo em seu lugar.

Além disso, se você está construindo qualquer coisa com infraestrutura de servidor Minecraft - talvez procurando por comportamento de bloco ou tentando entender como funcionam as mecânicas complexas do jogo - você encontrará referências ao Waterfall em fóruns e documentação. Entender seu papel no ecossistema ajuda você a entender toda a paisagem.

Precisa descobrir blocos Minecraft para seu proxy ou servidor? A Ferramenta de Busca de Blocos é surpreendentemente útil quando você está depurando problemas de proxy ou entendendo por que certos blocos causam problemas com roteamento de pacotes.