Libwebsockets

Libwebsockets é uma biblioteca C pura, com licença MIT, simples de usar, que fornece cliente e servidor para http/1 , http/2 , websockets , MQTT e outros protocolos de maneira leve, configurável, escalonável e flexível. É fácil de construir e construir cruzadamente via cmake e é adequado para tarefas de RTOS incorporados até serviço em nuvem em massa.

Ele oferece suporte a muitas implementações auxiliares leves para coisas como JSON, CBOR, JOSE, COSE e oferece suporte a OpenSSL e MbedTLS v2 e v3 prontos para uso para tudo. É muito gregário quando se trata de compartilhamento de loop de eventos, suportando libuv, libevent, libev, sdevent, glib e uloop, bem como bibliotecas de eventos personalizadas.

Mais de 100 exemplos mínimos independentes para vários cenários, licenciados CC0 (domínio público) para recortar e colar, permitem que você comece rapidamente.

Existem muitos READMEs sobre uma variedade de tópicos.

Fazemos uma grande quantidade de testes de CI por push, atualmente 582 compilações em 30 plataformas. Você pode ver o rack lws CI e ler sobre como o Sai baseado em lws é usado para coordenar todos os testes.

visão geral

Notícias

Pilha de exibição HTML + CSS + JPEG + PNG em lws

Quer controlar seu display EPD ou TFT/OLED usando HTML + CSS? Só tem um ESP32?

Deseja JPEGs, PNGs, HTML, composição RGBA, gama e difusão de erros remotos, se necessário?

Renderização em tempo real em um buffer de linha porque você não tem heap suficiente para um framebuffer?

Dê uma olhada aqui...

Ligação Perl para lws disponível

Graças a Felipe Gasper, agora existe uma ligação perl para lws disponível no metacpan, que usa o recente suporte genérico de loop de eventos em lws para ter lws como convidado em um loop de eventos perl existente.

Exemplos de LWS mudando para Secure Streams

Streams seguros diretos

O suporte Secure Streams no lws foi introduzido há alguns anos, é uma interface de nível superior para lws wsi -level apis que simplifica a conectividade segregando a política de conexão, como protocolo e informações de endpoint em um arquivo de política JSON separado, e apenas tendo o código tratado com cargas úteis; o máximo possível de detalhes do protocolo de ligação são ocultados ou movidos para a política, de modo que o código do usuário é quase idêntico, mesmo se o protocolo de ligação for alterado.

O código do usuário apenas pede para criar um SS por "streamtype name", ele é criado de acordo com os detalhes (protocolo, endpoint, etc) com o mesmo nome na política.

As principais entradas de política, como endpoint, podem conter substituições de string ${metadata-name} para lidar com adaptações de tempo de execução por meio de metadados. h1, h2, ws e mqtt são suportados.

Como uma camada sobre as APIs wsi , o SS fornece uma maneira de nível superior de acessar os recursos existentes de nível wsi; ambos os tipos de API permanecerão suportados. Os Secure Streams têm vida mais longa do que um único wsi, portanto, um SS pode coordenar novas tentativas sozinho. O código de usuário baseado em SS é normalmente significativamente menor e mais fácil de manter do que a camada wsi.

No ramo principal, movi os exemplos mais antigos para ./minimal-examples-lowlevel e estou começando a transferir mais casos de lá para exemplos baseados em SS.

Comparação entre uso de lws de nível wsi e SS

Recurso	maneira wsi de "baixo nível"	Maneira de fluxos seguros
Crie contexto	código	mesmo
Suporte de loop, sul agendador	padrão, bibliotecas de eventos	mesmo
Suporta modo de comunicação	Cliente, Servidor, Bruto	mesmo
Suporta protocolos	h1, h2, ws, mqtt (cliente)	mesmo
Suporte TLS	mbedtls (incluindo v3), openssl (incluindo v3), wolfssl, chatssl, libressl	mesmo
Serializável, proxiável, muxável, transportável	Não	Sim
Objeto de usuário alocado automaticamente por conexão	pss especificado em lws_protocols	Especificado na estrutura de informações ss
API de usuário de conexão	lws_protocols cbs específicos do protocolo (> 100)	API SS (somente retornos de chamada de rx, tx e estado)
Envio de adaptação	lws_callback_on_writeable() + WRITEABLE	lws_ss_request_write() + tx() cb
Enviando buffer	Tratamento parcial escolhido pelo usuário + malloc'd	Fornecido por SS, sem parciais
Criar vhosts	código	Política JSON
Validação TLS	pacote ou código de certificado	Política JSON ou pacote de certificados
Nova tentativa/retirada de conexão	código	Política JSON , Automático
Pregando	código	Política JSON , Automático
Detalhes do endpoint e do protocolo	espalhado pelo código	Política JSON
Seleção de protocolo, compartilhamento de pipeline/stream	código	Política JSON
seleção de subprotocolo ws	código	Política JSON
ws binário / texto	código	Política JSON
Metadados específicos do protocolo	APIs específicas do protocolo no código (por exemplo, lws_hdr)	Política JSON , APIs de metadados genéricos no código
Regras de validade de conexão	estrutura	Política JSON , Automático
Transmitir como enquete longa	código	Política JSON
Autenticação	código	Política JSON + rotação automática se o provedor for compatível, caso contrário, código

Fluxos seguros serializados

Streams seguros diretos

As APIs Secure Streams também são serializáveis , o mesmo código do cliente pode cumprir a conexão diretamente no mesmo processo que você esperaria ou encaminhar as ações, metadados e cargas úteis para um proxy SS que possui a política em um domínio Unix ou conexão de soquete TCP ser cumprida centralmente. Isto permite, por exemplo, fluxos h2 de diferentes processos compartilhando uma única conexão.

Streams seguros diretos

O SS serializado também pode viajar por transportes genéricos como UART, um exemplo é fornecido implementando o exemplo Binance em um RPi Pico com um transporte UART para um proxy SS de transporte UART, onde o pico em si não tem pilha de rede, tls, compactação ou pilha wss , mas pode enviar e receber de e para o endpoint como se o fizesse.

O lws_trasport_mux opcional é usado para se interpor entre o transporte UART e a camada SSPC, permitindo que um único canal transporte muitas conexões SS separadas.

O código SS do usuário é idêntico, porém é transportado, agrupado e preenchido.

v4.3 é lançado

Veja o changelog

Retrospectiva do trabalho Lws

O commit inicial para lws terá sido há 11 anos, em 28 de outubro de 2021, tem sido muito trabalhoso. Há um total de 4,3 mil patches, chegando a 800 KLOC cumulativamente (este não é o tamanho do repositório, mas ao longo dos anos, quantas linhas de origem foram alteradas pelos patches).

visão geral

Felizmente, ao longo dos anos, cerca de 15% disso foi contribuído por 404 colaboradores: isso não é tão ruim. Muito obrigado a todos que forneceram patches.

Hoje, pelo menos dezenas de milhões de dispositivos e recursos de produtos dependem do lws para lidar com suas comunicações, incluindo vários da FAANG; O Google agora inclui o LWS como parte das fontes do Android.