libwebsockets
1.0.0
Libwebsockets es una biblioteca C pura, con licencia MIT y fácil de usar que proporciona cliente y servidor para http/1 , http/2 , websockets , MQTT y otros protocolos de una manera segura, liviana, configurable, escalable y flexible. Es fácil de construir y cruzar a través de cmake y es adecuado para tareas desde RTOS integrado hasta servicio masivo en la nube.
Admite muchas implementaciones auxiliares livianas para cosas como JSON, CBOR, JOSE, COSE, y admite OpenSSL y MbedTLS v2 y v3 listos para usar para todo. Es muy sociable cuando se trata de compartir bucles de eventos, y admite libuv, libevent, libev, sdevent, glib y uloop, así como bibliotecas de eventos personalizadas.
Más de 100 ejemplos mínimos independientes para diversos escenarios, con licencia CC0 (dominio público) para cortar y pegar, le permiten comenzar rápidamente.
Hay muchos archivos README sobre una variedad de temas.
Realizamos una gran cantidad de pruebas de CI por impulso, actualmente 582 compilaciones en 30 plataformas. Puede ver el bastidor de CI de lws y leer sobre cómo se utiliza Sai basado en lws para coordinar todas las pruebas.
¿Quiere controlar su pantalla EPD o TFT/OLED usando HTML + CSS? ¿Solo tienes ESP32?
¿Quiere archivos JPEG, PNG, HTML, composición RGBA, gamma y difusión de errores remotos si es necesario?
¿Renderizar en tiempo real en un búfer de línea porque no tienes suficiente montón para un búfer de fotogramas?
Échale un vistazo aquí...
Gracias a Felipe Gasper, ahora hay un enlace de perl para lws disponible en metacpan, que utiliza el reciente soporte de bucle de eventos genérico en lws para tener a lws como invitado en un bucle de eventos de perl existente.
El soporte de Secure Streams en lws se introdujo hace un par de años, es una interfaz de nivel superior para las apis de nivel wsi de lws que simplifica la conectividad al segregar la política de conexión, como el protocolo y la información del punto final, en un archivo de política JSON separado, y solo tener el código con cargas útiles; Se ocultan o se mueven a la política tantos detalles del protocolo de conexión como sea posible, por lo que el código de usuario es casi idéntico incluso si el protocolo de conexión cambia.
El código de usuario simplemente solicita crear un SS por "nombre de tipo de flujo", se crea de acuerdo con los detalles (protocolo, punto final, etc.) bajo el mismo nombre en la política.
Las entradas de políticas clave, como el punto final, pueden contener sustituciones de cadenas ${metadata-name} para manejar adaptaciones en tiempo de ejecución a través de metadatos. Se admiten h1, h2, ws y mqtt.
Como capa encima de las API wsi , SS proporciona una forma de nivel superior para acceder a las capacidades de nivel WSI existentes; ambos tipos de API seguirán siendo compatibles. Los Secure Streams tienen una vida más larga que un solo wsi, por lo que un SS puede coordinar los reintentos por sí mismo. El código de usuario basado en SS suele ser significativamente más pequeño y más fácil de mantener que la capa wsi.
En la rama principal, moví los ejemplos más antiguos a ./minimal-examples-lowlevel y estoy empezando a trasladar más casos desde allí a ejemplos basados en SS.
| Característica | Modo wsi de "bajo nivel" | Manera de transmisiones seguras |
|---|---|---|
| Crear contexto | código | mismo |
| Soporte de bucle, planificador sul | predeterminado, bibliotecas de eventos | mismo |
| Soporta modo de comunicaciones | Cliente, Servidor, Sin procesar | mismo |
| Soporta protocolos | h1, h2, ws, mqtt (cliente) | mismo |
| Soporte TLS | mbedtls (incluido v3), openssl (incluido v3), wolfssl, aburridossl, libressl | mismo |
| Serializable, proxiable, muxable, transportable | No | Sí |
| Objeto de usuario por conexión asignado automáticamente | pss especificado en lws_protocols | Especificado en la estructura ss info |
| API de usuario de conexión | Lws_protocols cbs específicos del protocolo (> 100) | SS API (rx, tx, devoluciones de llamada de estado únicamente) |
| Envío de adaptación | lws_callback_on_writeable() + ESCRIBIBLE | lws_ss_request_write() + tx() cb |
| Búfer de envío | Manejo parcial elegido por el usuario + malloc | Proporcionado por SS, sin parciales |
| Crear hosts virtuales | código | política JSON |
| Validación TLS | paquete o código de certificado | Política JSON o paquete de certificados |
| Reintento/retroceso de conexión | código | Política JSON , Automática |
| Clavando | código | Política JSON , Automática |
| Detalles de protocolo y punto final | difundir alrededor del código | política JSON |
| Selección de protocolo, intercambio de canalización/transmisión | código | política JSON |
| selección de subprotocolo ws | código | política JSON |
| ws binario/texto | código | política JSON |
| Metadatos específicos del protocolo | API específicas del protocolo en el código (p. ej., lws_hdr) | Política JSON , API de metadatos genéricos en el código |
| Reglas de validez de conexión | estructura | Política JSON , Automática |
| Transmitir como encuesta larga | código | política JSON |
| autenticación | código | Política JSON + rotación automática si el proveedor es compatible; de lo contrario, código |
Las API de Secure Streams también son serializables , exactamente el mismo código de cliente puede completar la conexión directamente en el mismo proceso que se esperaría, o reenviar las acciones, metadatos y cargas útiles a un SS Proxy que posee la política a través de un dominio Unix o una conexión de socket TCP. cumplirse de forma centralizada. Esto permite, por ejemplo, que flujos h2 de diferentes procesos compartan una única conexión.
El SS serializado también puede viajar a través de transportes genéricos como UART; se proporciona un ejemplo implementando el ejemplo de Binance en un RPi Pico con un transporte UART a un proxy SS de transporte UART, donde el pico en sí no tiene pila de red, tls, compresión o pila wss. , pero puede enviar y recibir desde y hacia el punto final como si lo hiciera.
El lws_trasport_mux opcional se utiliza para interponerse entre el transporte UART y la capa SSPC, lo que permite que una sola tubería transporte muchas conexiones SS separadas.
El código SS del usuario es idéntico sin embargo se transporta, se mezcla y se cumple.
Ver el registro de cambios
El compromiso inicial para lws habrá sido hace 11 años, el 28 de octubre de 2021, ha sido mucho trabajo. Hay un total de 4.3K parches, alcanzando 800KLOC acumulativamente (este no es el tamaño en el repositorio, pero a lo largo de los años, cuántas líneas fuente fueron modificadas por los parches).
Es gratificante que, a lo largo de los años, aproximadamente el 15 % de esa cantidad fue aportada por 404 contribuyentes: eso no es tan malo. Muchas gracias a todos los que han proporcionado parches.
Hoy en día, al menos decenas de millones de dispositivos y características de productos dependen de lws para manejar sus comunicaciones, incluidos varios de FAANG; Google ahora incluye lws como parte de las fuentes de Android.
Esta es la biblioteca C libwebsockets para clientes y servidores websocket ligeros. Para obtener ayuda, visite
https://libwebsockets.org
y considere unirse a la lista de correo del proyecto en
https://libwebsockets.org/mailman/listinfo/libwebsockets
Puedes obtener la última versión de la biblioteca desde git:
Documentos de la API de Doxygen para desarrollo: https://libwebsockets.org/lws-api-doc-main/html/index.html
