# Spec – Redutor de Ping (baseado no Packet-Bender)

Versão 0.1 – rascunho para teste comercial

## Um convite

E aí! A gente leu o seu blog e ficou impressionado com o Packet-Bender. Você resolveu sozinho, no terminal, um problema pelo qual muita gente paga todo mês.

A proposta é simples: testar se esse projeto pode virar um produto de verdade, com você no centro. Ninguém conhece esse código melhor do que você, então a ideia é que você lidere a parte técnica e a gente ajude com estrutura, testes e o lado comercial.

Você escreveu que "só o que está morto não muda". Talvez este seja um bom projeto para colocar isso em prática. Abaixo está um rascunho de como poderia funcionar. Tudo aqui está aberto para você mudar.

## 1. Objetivo

Validar se um redutor de ping simples, barato e focado no Brasil consegue atrair jogadores pagantes. A ideia é transformar o Packet-Bender, projeto do autor do neolime.net, em um produto que qualquer jogador consiga usar.

**Pré-requisito:** o Packet-Bender é seu. Se topar seguir depois do teste, a gente formaliza a sua participação (como sócio ou com outro acordo que faça sentido para você) e revisa juntos a licença do repositório.

## 2. Problema e proposta

- Jogadores sofrem com ping alto e oscilação (jitter) em jogos como CS2.
- Concorrentes como ExitLag e NoPing cobram em torno de US$ 6 a 10 por mês.
- Proposta: serviço mais barato, com foco em rotas brasileiras e na América do Sul e custo operacional baixo graças à infraestrutura sob demanda.

## 3. Escopo do protótipo (MVP)

Entra:

- Um jogo: CS2.
- Uma ou duas regiões de servidor (ex.: São Paulo).
- App para Windows com um botão "Conectar" e o ping em tempo real.
- Split tunneling: só o tráfego do jogo passa pelo túnel.
- Login simples e controle de acesso para testadores.

Fica fora:

- Cobrança automática, vários jogos, macOS e Linux para o público geral, painel avançado.

## 4. Arquitetura híbrida (serverless + sob demanda)

**Fluxo:**

1. O jogador abre o app e clica em "Conectar".
2. O app chama uma API serverless (API Gateway + Lambda).
3. A Lambda verifica se já existe um servidor ligado na região. Se não houver, liga uma instância (EC2 ou equivalente) a partir de uma imagem pronta com WireGuard.
4. A Lambda devolve ao app a configuração do túnel quando a máquina fica pronta.
5. Um agendador (EventBridge + Lambda) checa a cada 5 a 10 minutos se há jogadores conectados. Se o servidor ficar ocioso por mais de 15 minutos, desliga.

**Componentes:**

- API e autenticação: Lambda + API Gateway (ou Cloudflare Workers).
- Estado: DynamoDB com sessões ativas, servidores ligados e chaves dos usuários.
- Servidores de túnel: instâncias pequenas com WireGuard, ligadas sob demanda.
- App cliente: evolução do Packet-Bender para Windows, com interface gráfica simples.

**Trade-off conhecido:** a primeira conexão em uma região desligada leva de 30 a 60 segundos para a máquina ligar. Mitigações: mostrar "preparando servidor" no app; manter uma máquina ligada nos horários de pico; usar imagem enxuta para iniciar mais rápido.

**Alternativa para a fase de teste:** usar o plano gratuito da Oracle Cloud com uma máquina sempre ligada, para validar o produto antes de investir na automação.

## 5. Custos estimados (ordem de grandeza)

- Tráfego de jogo: cerca de 50 a 100 MB por hora por jogador, ou seja, muito baixo.
- Servidor pequeno: em torno de US$ 5 a 10 por mês se ficar ligado direto; menos no modelo sob demanda.
- Lambda, API Gateway e DynamoDB: praticamente zero na escala do teste.
- Taxa de pagamento: em torno de 5% por transação.
- Preço mínimo viável estimado: R$ 5 a 7 por mês por jogador cobre a operação com folga.

Observação: são estimativas; precisam ser confirmadas com as calculadoras do provedor escolhido.

## 6. Segurança (para revisar com o time)

- Chaves WireGuard únicas por usuário, revogáveis.
- Nada de tráfego fora do jogo pelo túnel (reduz risco e custo).
- Servidores com portas mínimas abertas e atualização automática.
- Lambdas com permissões mínimas para ligar e desligar só as instâncias do projeto.
- Logs sem guardar conteúdo de tráfego; atenção à LGPD nos dados de cadastro.
- Proteção contra abuso: limite de sessões por conta e bloqueio de uso como VPN genérica.

## 7. Riscos e pontos jurídicos

- Termos de uso dos jogos e sistemas anticheat: confirmar que rotear tráfego por túnel é permitido (os concorrentes operam legalmente, mas é preciso verificar).
- Termos do provedor de nuvem para uso comercial de VPN.
- Propriedade do código: acordo claro com o autor do Packet-Bender.

## 8. Plano de teste

**Fase 1 – Técnica (2 a 3 semanas):** um servidor, 5 a 10 amigos jogando CS2. Medir ping, jitter e perda de pacotes com e sem o túnel.

**Fase 2 – Sob demanda (2 semanas):** ativar Lambda para ligar e desligar servidores; medir tempo de inicialização e custo real.

**Fase 3 – Comercial (4 semanas):** 50 a 100 testadores, landing page com preço, teste gratuito de 7 dias e pagamento manual ou por Pix.

## 9. Métricas de sucesso

- Redução média de ping de pelo menos 15% nas rotas testadas.
- Pelo menos 20% dos testadores aceitam pagar após o teste gratuito.
- Custo operacional por jogador abaixo de R$ 2 por mês.
- Tempo de inicialização sob demanda abaixo de 60 segundos.

## 10. Próximos passos

1. Conversar com o autor do Packet-Bender e fechar o acordo.
2. Revisar esta spec com o time de segurança.
3. Montar o servidor de teste e o app Windows básico.
4. Recrutar os primeiros testadores.