libwebsockets
1.0.0
Libwebsockets est une bibliothèque C pure simple à utiliser, sous licence MIT, fournissant client et serveur pour http/1 , http/2 , websockets , MQTT et d'autres protocoles d'une manière axée sur la sécurité, légère, configurable, évolutive et flexible. Il est facile à créer et à créer de manière croisée via cmake et convient aux tâches allant du RTOS intégré au service cloud de masse.
Il prend en charge de nombreuses implémentations auxiliaires légères pour des éléments tels que JSON, CBOR, JOSE, COSE, et prend en charge OpenSSL et MbedTLS v2 et v3 prêts à l'emploi pour tout. Il est très grégaire en matière de partage de boucles d'événements, prenant en charge libuv, libevent, libev, sdevent, glib et uloop, ainsi que les bibliothèques d'événements personnalisées.
Plus de 100 exemples minimaux indépendants pour divers scénarios, sous licence CC0 (domaine public) pour copier-coller, vous permettent de démarrer rapidement.
Il existe de nombreux README sur une variété de sujets.
Nous effectuons une énorme quantité de tests CI par push, actuellement 582 builds sur 30 plates-formes. Vous pouvez voir le rack lws CI et découvrir comment Sai basé sur lws est utilisé pour coordonner tous les tests.
Vous souhaitez piloter votre écran EPD ou TFT/OLED en utilisant HTML + CSS ? Vous n'avez qu'un ESP32 ?
Vous souhaitez des fichiers JPEG, PNG, HTML, composition RGBA, gamma, diffusion d'erreurs à distance si nécessaire ?
Rendu en temps réel dans un tampon de ligne parce que vous n'avez pas assez de tas pour un framebuffer ?
Jetez un oeil ici...
Grâce à Felipe Gasper, il existe désormais une liaison Perl pour lws disponible sur métacpan, elle utilise la récente prise en charge des boucles d'événements génériques dans lws pour avoir lws en tant qu'invité sur une boucle d'événements Perl existante.
La prise en charge de Secure Streams dans lws a été introduite il y a quelques années. Il s'agit d'une interface de niveau supérieur vers les API de niveau lws wsi qui simplifie la connectivité en séparant les politiques de connexion telles que les informations de protocole et de point de terminaison dans un fichier de politique JSON distinct, et en ayant simplement le code. avec des charges utiles ; autant de détails que possible sur le protocole filaire sont masqués ou déplacés vers la stratégie, de sorte que le code utilisateur est presque identique même si le protocole filaire change.
Le code utilisateur demande simplement de créer un SS par "streamtype name", il est créé selon les détails (protocole, point de terminaison, etc.) sous le même nom dans la politique.
Les entrées de stratégie clés telles que le point de terminaison peuvent contenir des substitutions de chaîne ${metadata-name} pour gérer les adaptations d'exécution via les métadonnées. h1, h2, ws et mqtt sont pris en charge.
En tant que couche au-dessus des API wsi , SS fournit un moyen de niveau supérieur d'accéder aux fonctionnalités existantes de niveau wsi, les deux types d'API resteront pris en charge. Les flux sécurisés ont une durée de vie plus longue qu'un seul wsi, de sorte qu'un SS peut coordonner lui-même les tentatives. Le code utilisateur basé sur SS est généralement nettement plus petit et plus maintenable que la couche wsi.
Dans la branche principale, j'ai déplacé les anciens exemples vers ./minimal-examples-lowlevel et je commence à porter davantage de cas à partir de là vers des exemples basés sur SS.
| Fonctionnalité | manière wsi "de bas niveau" | Méthode de flux sécurisé |
|---|---|---|
| Créer un contexte | code | même |
| Prise en charge des boucles, sur le planificateur | par défaut, bibliothèques d'événements | même |
| Prend en charge le mode de communication | Client, Serveur, Brut | même |
| Prend en charge les protocoles | h1, h2, ws, mqtt (client) | même |
| Prise en charge de TLS | mbedtls (y compris v3), openssl (y compris v3), wolfssl, ennuyeuxssl, libressl | même |
| Sérialisable, proxy, multiplexable, transportable | Non | Oui |
| Objet utilisateur alloué automatiquement par connexion | pss spécifié dans lws_protocols | Spécifié dans la structure ss info |
| API utilisateur de connexion | lws_protocols cbs spécifiques au protocole (> 100) | API SS (rx, tx, rappels d'état uniquement) |
| Envoi de l'adaptation | lws_callback_on_writeable() + ÉCRIVABLE | lws_ss_request_write() + tx() cb |
| Tampon d'envoi | Gestion partielle choisie par l'utilisateur + mallocée | Fourni par SS, pas de partiels |
| Créer des hôtes virtuels | code | Politique JSON |
| Validation TLS | paquet ou code de certificat | Politique JSON ou ensemble de certificats |
| Nouvelle tentative de connexion/interruption | code | Politique JSON , Automatique |
| Clouage | code | Politique JSON , Automatique |
| Détails du point de terminaison et du protocole | répartis autour du code | Politique JSON |
| Sélection de protocole, partage de pipeline/flux | code | Politique JSON |
| sélection du sous-protocole ws | code | Politique JSON |
| ws binaire / texte | code | Politique JSON |
| Métadonnées spécifiques au protocole | API spécifiques au protocole dans le code (par exemple, lws_hdr) | Politique JSON , API de métadonnées génériques dans le code |
| Règles de validité de connexion | structurer | Politique JSON , Automatique |
| Diffusez en tant que sondage long | code | Politique JSON |
| Authentification | code | Politique JSON + rotation automatique si fournisseur pris en charge, sinon code |
Les API Secure Streams sont également sérialisables , le même code client exact peut établir la connexion directement dans le même processus que prévu, ou transmettre les actions, les métadonnées et les charges utiles à un proxy SS qui possède la politique via un domaine Unix ou une connexion socket TCP. à remplir de manière centralisée. Cela permet, par exemple, aux flux h2 provenant de différents processus de partager une seule connexion.
Le SS sérialisé peut également voyager sur des transports génériques comme UART, un exemple est fourni implémentant l'exemple Binance sur un RPi Pico avec un transport UART vers un proxy SS de transport UART, où le pico lui-même n'a pas de pile réseau, de tls, de compression ou de pile wss. , mais peut envoyer et recevoir vers et depuis le point de terminaison comme si c'était le cas.
Le lws_trasport_mux facultatif est utilisé pour s'interposer entre le transport UART et la couche SSPC, permettant à un seul canal de transporter de nombreuses connexions SS distinctes.
Le code SS utilisateur est identique mais il est transporté, multiplexé et exécuté.
Voir le changelog
Le commit initial pour lws aura eu lieu il y a 11 ans, le 28 octobre 2021, cela a demandé beaucoup de travail. Il y a un total de 4,3K correctifs, touchant 800KLOC cumulativement (ce n'est pas la taille dans le dépôt, mais au fil des années, combien de lignes sources ont été modifiées par les correctifs).
Heureusement, il s'avère qu'au fil des ans, environ 15 % de cette somme a été versée par 404 contributeurs : ce n'est pas si mal. Merci beaucoup à tous ceux qui ont fourni des correctifs.
Aujourd'hui, au moins des dizaines de millions d'appareils et de fonctionnalités de produits s'appuient sur LWS pour gérer leurs communications, dont plusieurs de FAANG ; Google inclut désormais lws dans les sources Android.
Il s'agit de la bibliothèque C libwebsockets pour les clients et serveurs websocket légers. Pour obtenir de l'aide, visitez
https://libwebsockets.org
et envisagez de rejoindre la liste de diffusion du projet à
https://libwebsockets.org/mailman/listinfo/libwebsockets
Vous pouvez obtenir la dernière version de la bibliothèque depuis git :
Documentation de l'API Doxygen pour le développement : https://libwebsockets.org/lws-api-doc-main/html/index.html
