Experimental bidirectional emulation layer, session for uni transports

[FZambia]

Experimental bidirectional layer

Here we inherit experimental Centrifuge features - just to make Centrifugo capable to work with the latest client protocol.

This includes our own emulation layer and 2 new transports which work over it

• HTTP-streaming
• SSE (Eventsource)

The main idea behind emulation layer: make centrifuge-js capable to work with corporate proxies which block WebSocket traffic, fallback automatically with possibility to not use SockJS (and all its overhead) and sticky sessions in setup involving multiple Centrifugo nodes.

At this point this all experimental here and only works with client centrifuge-js from v3_dev branch. These features won't be documented for now, but I'll try to encourage users to check them out to get more feedback.

Basically, two main options added here are boolean sse which enables SSE/EventSource (transport available on /connection/sse by default) and boolean http_stream which enables HTTP-streaming (transport available on /connection/http_stream by default). As soon as enabled we also start emulation handler endpoint (/emulation by default).

After enabling it's possible to use these transports when configuring centrifuge-js (again - only from centrifuge-js v3_dev branch at this point):

const transports = [
    {
        transport: 'websocket',
        endpoint: 'ws://example.com/connection/websocket?cf_protocol_version=v2'
    },
    {
        transport: 'http_stream',
        endpoint: 'http://example.com/connection/http_stream'
    },
    {
        transport: 'sse',
        endpoint: 'http://example.com/connection/sse'
    },
];
const centrifuge = new Centrifuge(transports, {});

Note, that centrifuge-js only works using client protocol v2, that's why we force it in the example above using cf_protocol_version=v2 when connecting to Centrifugo. HTTP-streaming and SSE endpoint only support client protocol v2 – so we can avoid using cf_protocol_version in endpoints.

This issue is a part of ongoing Centrifugo v4 work and corresponds to latest state described in comment.

Session for unidirectional transports

Also, we support session string field for unidirectional transports here (unique string attached to connection on start, in addition to client ID). It allows to control unidirectional connections using server API. Previously we used client ID for this – but turns out it's not really working approach since client ID can be exposed to other users in Publications, presence, join/leave – so backend can not distinguish whether user passed its own client ID or not. With session which is not shared at all things work in a more secure manner.