rnl

Aviso

O RNL, incluindo seu código de criptografia, não foi auditado até o momento, portanto, o RNL se destina apenas a jogos em tempo real e aplicativos multimídia sem processamento de nenhum com dados críticos, mas não para aplicativos sérios com dados críticos!

Descrição

RNL significa "Biblioteca de Rede em Tempo Real"

RNL é uma biblioteca de rede baseada em UDP para aplicativos e jogos em tempo real, inspirada em ENet, yojimbo, libgren e assim por diante.

O RNL foi projetado em torno de padrões comuns usados ​​em jogos em tempo real, que são vinculados à simulação, não vinculados à E/S e completamente com estado, portanto, a E/S assíncrona não faz muito sentido. Portanto, o design do núcleo RNL é de thread único, não de thread único. Mas você pode usar várias instâncias TRNLHost dentro de vários threads diferentes (uma a muito poucas instâncias por thread), para poder hospedar várias partidas de jogos em rede na mesma máquina, desde que essa máquina seja forte e rápida o suficiente para hospedar vários partidas de jogos em rede ao mesmo tempo.

E no lado do cliente do jogo, todo o material da rede deve rodar, se possível, em um thread próprio (também se possível, fixado no núcleo da CPU), para possíveis poucas interferências e outros problemas semelhantes. (offtopic: o mesmo também se aplica ao thread de áudio, a menos que alguém goste de possíveis problemas de saturação do buffer de áudio e assim por diante, quando não obteve tempo de CPU suficiente nos momentos certos. :-))

E para jogos maiores com muitos clientes em um único mundo de jogo, você deve usar várias instâncias TRNLHost subdivididas, de modo que cada TRNLHost deva lidar com apenas alguns clientes conectados, em vários threads e isso, por sua vez, em vários servidores físicos dedicados, que também por sua vez podem se comunicar entre si para imitar a impressão de um único mundo de jogo muito grande. Pelo menos uma única instância TRNLHost é projetada para números típicos de clientes baixos, já que esse é o caso típico de egoshooters, jogos de corrida e assim por diante. Ou, em outras palavras, para grandes mundos de jogo com massas de clientes: Dividir e conquistar (por exemplo, com setores de mundo de jogo parcialmente sobrepostos nas fronteiras dos setores, apenas como exemplo de uma ideia conceitual de dividir e conquistar)

Apoie-me

Apoie-me no Patreon

Características

• Principalmente design de código totalmente orientado a objetos
• Suporte IPv6
• Plataforma cruzada
  • Windows (com FreePascal e Delphi)
  • Linux (com FreePascal)
  • *BSD (com FreePascal)
  • Android (com FreePascal e Delphi)
  • Darwin (MacOS(X) e iOS) (com FreePascal e Delphi)
• Protocolo baseado em UDP
• Sequenciamento
• Canais
  • Com os seguintes possíveis tipos de canais configuráveis ​​gratuitamente:
    • Pedido confiável
    • Confiável não ordenado
    • Pedido não confiável
    • Não confiável não ordenado
• Confiabilidade
• Fragmentação e remontagem
• Agregação
• Adaptabilidade
• Portabilidade
• Possibilidade de usar um modelo peer-to-peer ou mesmo um modelo híbrido peer-to-peer e cliente/servidor misto em vez de apenas um modelo cliente/servidor puro e, claro, também de um modelo cliente/servidor clássico
• Gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG)
  • Baseado em arc4random, mas com ChaCha20 em vez de RC4 como bloco de construção básico
  • Múltiplas fontes de entropia (porque você nunca deve confiar em uma única fonte de entropia, pois ela pode ter um backdoor)
    • Incluindo o uso das instruções rdseed/rdrand em processadores x86 mais recentes como uma fonte de entropia opcional adicional quase baseada em hardware, se essas instruções forem suportadas pelo processador em execução atual
• Autenticação mútua
  • Baseado em um protocolo tipo Station-to-Station (STS), que pressupõe que as partes tenham chaves de assinatura, que são usadas para assinar mensagens, fornecendo assim segurança de minificação contra ataques man-in-the-middle, ao contrário do Diffie- Método Hellman sem tais extensões.
  • As chaves privadas/públicas de longo prazo são chaves ED25519 e são usadas apenas para fins de assinatura
• Encaminhar sigilo usando curva elíptica efêmera Diffie-Hellman (curva 25519)
  • A consequência disto, juntamente com outros factos, é que cada ligação tem sempre novas chaves privadas e públicas diferentes de curto prazo em ambos os lados e, portanto, também novas chaves secretas partilhadas de curto prazo.
  • As chaves públicas/privadas de curto prazo são chaves X25519 e a chave secreta compartilhada de curto prazo é usada apenas para fins de criptografia baseada em AEAD
• Criptografia de pacote autenticada com dados associados (AEAD)
  • Baseado em ChaCha20 como cifra e Poly1305 como código de autenticação de mensagem criptográfica
• Proteção de repetição de dados de pacotes de aplicativos
  • Baseado em vários mecanismos de proteção na fase de estabelecimento da conexão e números de sequência de pacotes criptografados
• Mecanismo de estabelecimento de conexão atrasada como mecanismo adicional de minificação da superfície de ataque
• Tokens de conexão e autenticação (como uma opção opcional, onde você deve ter um canal de comunicação fora de banda separado, por exemplo, um back-end mestre baseado em HTTPS para gerar e lidar com essas coisas) como um mecanismo adicional de minificação de superfície de ataque contra amplificação DDoS ataques
  • Os tokens de conexão são transferidos em texto não criptografado, para que sejam verificados de forma rápida no primeiro pacote de dados de uma tentativa de conexão, sem a necessidade de descriptografar o token de conexão antes que seja possível verificar o token, portanto, para economize tempo de CPU neste ponto. Esta opção é principalmente para uso contra ataques de amplificação DDoS, o que significa que o servidor não responderá imediatamente se o token de conexão não corresponder ao primeiro pacote de dados de uma tentativa de conexão e, portanto, os ataques de amplificação DDoS simplesmente iriam para o nada. Consequentemente, esses tokens devem ser válidos apenas por um curto período de tempo, o que também se aplica ao backend mestre da sua infraestrutura.
  • Os tokens de autenticação são transferidos criptografados, após a troca de chave privada/pública, a geração de chave secreta compartilhada, etc. Os tokens de autenticação, em contraste com o token de conexão, NÃO são uma contramedida contra ataques da categoria DDoS, mas sim os tokens de autenticação são, como o nome sugere, apenas para fins de autenticação de canais de comunicação fora de banda separados, em outras palavras, como adicional proteção contra conexões não autorizadas, onde você pode verificar com mais detalhes no backend master da sua infraestrutura, antes que o "cliente" possa se conectar ao servidor real, onde toda a ação real acontece.
• Limitador de taxa de tentativa de conexão
  • Configurável com duas constantes, burst e período
• Limitador de taxa de largura de banda configurável
• Recurso de rede virtual opcional (por exemplo, para solução de loopback local sem API de rede rápida para partidas de jogo singleplayer, que ainda deve ser baseada no conceito de servidor/cliente)
• Simulador de interferência de rede (por exemplo, para casos de teste e assim por diante)
  • Probabilidade de perda de pacotes simulada configurável (para pacotes de entrada e de saída)
  • Latência simulada configurável (para pacotes de entrada e de saída)
  • Jitter simulado configurável (para pacotes de entrada e de saída)
  • Probabilidade de pacotes duplicados simulados configuráveis ​​(para pacotes de entrada e de saída)
• Mecanismo de ajuste de dificuldade de resposta de solicitação de desafio de conexão dinâmica
  • Configurável com um valor de fator
  • Baseado no mecanismo de determinação de estilo de suavização de histórico de quadros por segundo, mas apenas quadros por segundo, tentativas de conexão por segundo
• Mais algoritmos de compressão como opções
  • Deflate (um LZ77 compatível com fluxo de bits zlib e um híbrido canônico Huffman, apenas fixo-estático-canônico-huffman nesta implementação aqui no lado do compressor, mas o lado do descompressor tem todos os recursos)
  • LZBRRC (um compressor estilo LZ77 junto com um backend de codificador de faixa de entropia)
  • BRRC (um codificador de faixa de entropia de ordem 0 pura)
• CRC32C em vez de CRC32 (sem C no final)
• E muito mais coisas. . .

Recursos planejados (também conhecidos como Todo) em ordem aleatória de prioridades

• PENDÊNCIA

Diretrizes gerais para contribuidores de código

Diretrizes gerais para contribuidores de código

Licença

Licença zlib

Canal de IRC

Canal IRC #rnl no Freenode

Obrigado

• Agradecimentos a Lee Salzman da ENet como inspiração para as ideias básicas de implementação do design da API
• Obrigado a Glenn Fiedler pela inspiração para ideias de implementação orientadas para a segurança
• Agradecimentos a Sergey Ignatchenko ("No Bugs" Hare) pela inspiração também para ideias de implementação orientadas para a segurança