mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00

History

Andy Green d98101d1e3 plugins: generalize and provide public api Move the common plugin scanning dir stuff to be based on lws_dir, which already builds for windows. Previously this was done via dirent for unix and libuv for windows. Reduce the dl plat stuff to just wrap instantiation and destruction of dynlibs, establish common code in lib/misc/dir.c for plugin scanning itself. Migrate the libuv windows dl stuff to windows-plugins.c, so that he's available even if later libuv loop support becomes and event lib plugin. Remove the existing api exports scheme for plugins, just export a const struct now which has a fixed header type but then whatever you want afterwards depending on the class / purpose of the plugin. Place a "class" string in the header so there can be different kinds of plugins implying different types exported. Make the plugin apis public and add support for filter by class string, and per instantation / destruction callbacks so the subclassed header type can do its thing for the plugin class. The user provides a linked-list base for his class of plugins, so he can manage them completely separately and in user code / user export types. Rip out some last hangers-on from generic sessions / tables. This is all aimed at making the plugins support general enough so it can provide event lib plugins later.	2020-08-31 16:51:37 +01:00
..
protocol_lws_raw_proxy.c	plugins: generalize and provide public api	2020-08-31 16:51:37 +01:00
README.md	role: raw-proxy	2018-12-01 11:05:59 +08:00

Andy Green d98101d1e3 plugins: generalize and provide public api

Move the common plugin scanning dir stuff to be based on lws_dir, which
already builds for windows.  Previously this was done via dirent for unix
and libuv for windows.

Reduce the dl plat stuff to just wrap instantiation and destruction of
dynlibs, establish common code in lib/misc/dir.c for plugin scanning
itself.

Migrate the libuv windows dl stuff to windows-plugins.c, so that he's
available even if later libuv loop support becomes and event lib plugin.

Remove the existing api exports scheme for plugins, just export a const struct
now which has a fixed header type but then whatever you want afterwards depending
on the class / purpose of the plugin.  Place a "class" string in the header so
there can be different kinds of plugins implying different types exported.

Make the plugin apis public and add support for filter by class string, and
per instantation / destruction callbacks so the subclassed header type can
do its thing for the plugin class.  The user provides a linked-list base
for his class of plugins, so he can manage them completely separately and
in user code / user export types.

Rip out some last hangers-on from generic sessions / tables.

This is all aimed at making the plugins support general enough so it can
provide event lib plugins later.

2020-08-31 16:51:37 +01:00

protocol_lws_raw_proxy.c

plugins: generalize and provide public api

2020-08-31 16:51:37 +01:00

README.md

role: raw-proxy

2018-12-01 11:05:59 +08:00

README.md

raw-proxy plugin

Enabling for build

$ cmake .. -DLWS_ROLE_RAW_PROXY=1

configuration pvo

pvo	value meaning
onward	The onward proxy destination, in the form `ipv4:addr[:port]`

Note for vhost selection

Notice that since it proxies the packets "raw", there's no SNI or Host: header to resolve amongst multiple vhosts on the same listen port. So the vhost you associate with this protocol must be alone on its own port.

It's also possible to apply this or other role + protocols as a fallback after http[s] processing rejected the first packet from an incoming connection. See ./READMEs/README-http-fallback.md

Note for packet size

For throughput, since often one side is localhost that can handle larger packets easily, you should create the context used with this plugin with

	info.pt_serv_buf_size = 8192;

lwsws already does this.

Using with C

See the minimal example ./minimal-example/raw/minimal-raw-proxy for a working example of a vhost that accepts connections and then proxies them using this plugin. The example is almost all boilerplate for setting up the context and the pvo.

Using with lwsws

For a usage where the plugin "owns" the whole vhost, you should enable the plugin protocol on the vhost as usual, and specify the "onward" pvo with:

                "ws-protocols": [{
                        "raw-proxy": {
                         "status": "ok",
                         "onward": "ipv4:remote.address.com:port"
                        }
                 }],

and then define the vhost with:

    "apply-listen-accept": "1",
    "listen-accept-role": "raw-proxy",
    "listen-accept-protocol": "raw-proxy"

which tells it to apply the role and protocol as soon as a connection is accepted on the vhost.