Proxy-Workers

A worker of type = proxy allows for scaling across processes. Currently, a single “realm” must be run in a single “router worker” process (so that it may orchestrate all access, publications, etc). Router Realms can do a lot of work besides just the core work of the “dealer” and “broker” roles for a realm, and this is where Proxy workers come in. A proxy worker can do everything that a normal router worker does except for core WAMP things; a Proxy passes all this traffic off to a configured “backend” realm.

In concrete terms, a core router realm worker can accept only CBOR connections on Unix raw-socket connections and leave Proxy processes to terminate (possibly TLS) WebSocket connections, handle WAMP-level authentication, deserialize JSON, serve static Web content, serve “info” pages, etc. Using a Unix-domain backend connection leaves maximum CPU cycles for the single router worker.

A minimal example with one realm and two proxy workers is available in the Crossbar “proxy” example. You could of course have three or four (or more) Proxy workers if need be.

Proxy workers support all the same transports as Router Transports. It also supports a type called websocket-proxy which is the same as a websocket transport with the addition of a “backends” member, which tells the proxy how to connect to the backends. Currently, there must be exactly one backend.

parameter	description
backends	List of dicts containing client-type endpoint information (must have exactly one) (required)

Here is a complete example snippet (taken from the above example):