keel

Keel (Kernel Event Engine, Lightweight) é um substrato de rede assíncrono portátil escrito em C. Sua ideia central é uma camada de transporte neutra em relação ao modelo: abstrações semânticas de stream, listener e datagrama impulsionadas por um modelo de execução de prontidão ou conclusão, assentadas sobre uma costura de socket que não assume um sistema operacional. A arquitetura é organizada ao longo de três eixos ortogonais: - Eixo de eventos: backends de prontidão (epoll, kqueue, WSAPoll, poll) registram interesse e tentam novamente em EAGAIN; backends de conclusão (io_uring, IOCP) submetem operações de propriedade e coletam conclusões. Ambos ficam atrás de uma interface de loop de eventos pequena, e cada um mantém sua semântica nativa em vez de emular o outro. - Eixo de socket: uma vtable de provedor plugável (KlSocketProvider) com POSIX e Winsock embutidos, além de integrações fornecidas para lwIP (camada de socket BSD e uma pilha de callback NO_SYS bruta) e um provedor UEFI freestanding EFI_TCP4/UDP4. Flags de capacidade controlam recursos como fd nativo, writev e sendfile. - Eixo de protocolo: HTTP/1.1, HTTP/2, WebSocket, SSE e um resolvedor DNS assíncrono são consumidores do substrato, não seu propósito. O código de protocolo deve passar apenas pelas abstrações de conexão/stream e eventos, nunca diretamente para um cabeçalho de rede de plataforma ou motor de eventos; o projeto descreve portões de construção estruturais de negação padrão que falham se essa separação for violada. Recursos de protocolo e servidor incluem um parser HTTP plugável (llhttp fornecido), TLS plugável via vtable, leitores de corpo plugáveis, middleware por rota com curto-circuito, middleware CORS embutido, dados de formulário multipart RFC 2046, três modos de resposta (writev bufferizado, sendfile, streaming chunked), captura de parâmetros de rota sem alocação, timeouts de conexão com respostas 408 automáticas, registro de acesso, handlers de servidor assíncronos que suspendem e retomam conexões, clientes HTTP síncronos e assíncronos, um pool de threads com wakeup por pipe, observadores de fd genéricos, enquadramento SSE, compressão de resposta (gzip miniz) e descompressão de cliente, um pool de conexões keep-alive, seguir redirecionamentos, proxy HTTP e tunelamento CONNECT, um buffer de escrita com backpressure, agendamento de timers e códigos de erro estilo sqlite3. Extras de rede incluem servidores de socket de domínio UNIX com credenciais de peer, rótulos de segurança de peer, inspeção de certificado de cliente mTLS, suporte a protocolo PROXY controlado por CIDRs confiáveis, ativação de socket via fds herdados (LISTEN_FDS do systemd), named pipes do Windows sobre IOCP, uma API de datagrama UDP de slot fixo estável com agrupamento, multicast/broadcast, marcação ECN/TOS e suporte a offload, um resolvedor DNS assíncrono plugável com uma implementação dual-family embutida e corrida de conexão de cliente Happy Eyeballs. Opções de build cobrem backends epoll, kqueue, io_uring, poll e IOCP, Cosmopolitan C, MSVC nativo e hooks de embedder para flags de otimização. O README afirma 111K req/s em um único thread e testes sob ASan/UBSan em ambos os modelos de execução, com uma dependência fornecida (llhttp).