Libwebsockets

Libwebsockets ist eine benutzerfreundliche reine C-Bibliothek mit MIT-Lizenz, die Client und Server für http/1 , http/2 , Websockets , MQTT und andere Protokolle auf sicherheitsorientierte, leichte, konfigurierbare, skalierbare und flexible Weise bereitstellt. Es lässt sich einfach über cmake erstellen und Cross-Building durchführen und eignet sich für Aufgaben vom eingebetteten RTOS bis hin zur Massen-Cloud-Bereitstellung.

Es unterstützt viele einfache Zusatzimplementierungen für Dinge wie JSON, CBOR, JOSE, COSE und unterstützt OpenSSL und MbedTLS v2 und v3 sofort für alles. Es ist sehr gesellig, wenn es um die gemeinsame Nutzung von Ereignisschleifen geht und unterstützt libuv, libevent, libev, sdevent, glib und uloop sowie benutzerdefinierte Ereignisbibliotheken.

Über 100 unabhängige Minimalbeispiele für verschiedene Szenarien, CC0-lizenziert (Public Domain) zum Ausschneiden und Einfügen, ermöglichen Ihnen einen schnellen Einstieg.

Es gibt viele READMEs zu verschiedenen Themen.

Wir führen eine große Menge an CI-Tests pro Push durch, derzeit 582 Builds auf 30 Plattformen. Sie können sich das LWS-CI-Rack ansehen und erfahren, wie LWS-basiertes Sai zur Koordinierung aller Tests verwendet wird.

Überblick

Nachricht

HTML + CSS + JPEG + PNG-Anzeigestapel in LWS

Möchten Sie Ihr EPD- oder TFT-/OLED-Display mit HTML + CSS ansteuern? Du hast nur einen ESP32?

Möchten Sie bei Bedarf Remote-JPEGs, PNGs, HTML, RGBA-Komposition, Gamma und Fehlerdiffusion?

Echtzeit-Rendering in einen Zeilenpuffer, weil Sie nicht genug Heap für einen Framebuffer haben?

Schauen Sie hier...

Perl-Bindung für LWS verfügbar

Dank Felipe Gasper ist jetzt bei metacpan eine Perl-Bindung für LWS verfügbar. Diese nutzt die aktuelle Unterstützung für generische Ereignisschleifen in LWS, um LWS als Gast in einer vorhandenen Perl-Ereignisschleife zu haben.

Lws-Beispiele für den Wechsel zu Secure Streams

Sichere Streams direkt

Die Unterstützung von Secure Streams in LWS wurde vor ein paar Jahren eingeführt. Dabei handelt es sich um eine übergeordnete Schnittstelle zu LWS-APIs auf wsi -Ebene, die die Konnektivität vereinfacht, indem Verbindungsrichtlinien wie Protokoll- und Endpunktinformationen in einer separaten JSON-Richtliniendatei getrennt werden und nur der Code verwaltet wird mit Nutzlasten; So viele Details des Wire-Protokolls wie möglich werden ausgeblendet oder in die Richtlinie verschoben, sodass der Benutzercode nahezu identisch ist, selbst wenn sich das Wire-Protokoll ändert.

Der Benutzercode fordert lediglich dazu auf, einen SS anhand des „Streamtype-Namens“ zu erstellen. Dieser wird gemäß den Details (Protokoll, Endpunkt usw.) unter demselben Namen in der Richtlinie erstellt.

Wichtige Richtlinieneinträge wie Endpunkt können ${metadata-name} -String-Ersetzungen enthalten, um Laufzeitanpassungen über Metadaten zu verarbeiten. h1, h2, ws und mqtt werden unterstützt.

Als Schicht über der wsi -API bietet SS eine übergeordnete Möglichkeit, auf die vorhandenen Funktionen auf WSI-Ebene zuzugreifen. Beide Arten von APIs werden weiterhin unterstützt. Secure Streams sind langlebiger als ein einzelnes WSI, sodass ein SS Wiederholungsversuche selbst koordinieren kann. SS-basierter Benutzercode ist in der Regel deutlich kleiner und wartbarer als der WSI-Layer.

Im Hauptzweig habe ich die älteren Beispiele nach ./minimal-examples-lowlevel verschoben und beginne, von dort aus mehr Fälle in SS-basierte Beispiele zu portieren.

Vergleich zwischen WSI- und SS-Level-LWS-Nutzung

Besonderheit	„Low-Level“-WSI-Weg	Sichere Streams-Methode
Kontext schaffen	Code	Dasselbe
Loop-Unterstützung, auf dem Scheduler	Standardmäßig Ereignisbibliotheken	Dasselbe
Unterstützt den Kommunikationsmodus	Client, Server, Raw	Dasselbe
Unterstützt Protokolle	h1, h2, ws, mqtt (Client)	Dasselbe
TLS-Unterstützung	mbedtls (einschließlich v3), openssl (einschließlich v3), wolfssl, Boringssl, libressl	Dasselbe
Serialisierbar, proxiable, muxable, transportierbar	NEIN	Ja
Automatisch zugewiesenes Benutzerobjekt pro Verbindung	pss in lws_protocols angegeben	In der SS-Info-Struktur angegeben
Verbindungsbenutzer-API	Protokollspezifische lws_protocols cbs (> 100)	SS-API (nur Rx-, Tx- und Statusrückrufe)
Anpassung senden	lws_callback_on_writeable() + WRITEABLE	lws_ss_request_write() + tx() cb
Sendepuffer	Vom Benutzer gewählt + mallocierte Teilbehandlung	SS-bereitgestellt, keine Teiltöne
Erstellen Sie Vhosts	Code	JSON-Richtlinie
TLS-Validierung	Zertifikatspaket oder Code	JSON-Richtlinie oder Zertifikatspaket
Verbindungswiederholung/Backoff	Code	JSON-Richtlinie , Auto
Festnageln	Code	JSON-Richtlinie , Auto
Endpunkt- und Protokolldetails	im Code verteilen	JSON-Richtlinie
Protokollauswahl, Pipeline-/Stream-Sharing	Code	JSON-Richtlinie
Auswahl des ws-Unterprotokolls	Code	JSON-Richtlinie
ws binär / text	Code	JSON-Richtlinie
Protokollspezifische Metadaten	Protokollspezifische APIs im Code (z. B. lws_hdr)	JSON-Richtlinie , generische Metadaten-APIs im Code
Gültigkeitsregeln für Verbindungen	Struktur	JSON-Richtlinie , Auto
Als lange Umfrage streamen	Code	JSON-Richtlinie
Auth	Code	JSON-Richtlinie + automatische Rotation, wenn der Anbieter unterstützt wird, sonst Code

Serialisierte sichere Streams

Sichere Streams direkt

Secure Streams-APIs sind außerdem serialisierbar . Der exakt gleiche Client-Code kann die Verbindung direkt im gleichen Prozess herstellen, wie Sie es erwarten würden, oder die Aktionen, Metadaten und Nutzlasten über eine Unix-Domäne oder eine TCP-Socket-Verbindung an einen SS-Proxy weiterleiten, der die Richtlinie besitzt zentral zu erfüllen. Dies ermöglicht beispielsweise, dass sich H2-Streams aus verschiedenen Prozessen eine einzige Verbindung teilen.

Sichere Streams direkt

Der serialisierte SS kann auch über generische Transporte wie UART übertragen werden. Es wird ein Beispiel bereitgestellt, in dem das Binance-Beispiel auf einem RPi Pico mit einem UART-Transport zu einem UART-Transport-SS-Proxy implementiert wird, wobei der Pico selbst keinen Netzwerk-Stack, TLS, Komprimierung oder WSS-Stack hat , kann aber genauso an den Endpunkt senden und empfangen, als ob dies der Fall wäre.

Der optionale lws_trasport_mux wird verwendet, um zwischen dem UART-Transport und der SSPC-Schicht zu schalten, sodass eine einzelne Pipe viele separate SS-Verbindungen übertragen kann.

Der Benutzer-SS-Code ist identisch, wird jedoch transportiert, gemuxt und erfüllt.

v4.3 ist veröffentlicht

Siehe Changelog

LWS-Arbeitsrückblick

Der erste Commit für lws wird vor 11 Jahren, also am 28. Oktober 2021, stattgefunden haben, es war eine Menge Arbeit. Es gibt insgesamt 4,3K Patches, was zusammen 800KLOC entspricht (dies ist nicht die Größe im Repo, sondern wie viele Quellzeilen im Laufe der Jahre durch Patches geändert wurden).

Überblick

Erfreulicherweise stellte sich heraus, dass im Laufe der Jahre etwa 15 % davon von 404 Mitwirkenden beigesteuert wurden: Das ist gar nicht so schlecht. Vielen Dank an alle, die Patches bereitgestellt haben.

Heutzutage verlassen sich mindestens zig Millionen Geräte und Produktfunktionen auf lws, um ihre Kommunikation abzuwickeln, darunter mehrere von FAANG; Google integriert LWS jetzt in seine Android-Quellen.