[nanomsg] Re: WebSocket transport
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 15 Nov 2014 23:22:11 +0200
Hi,
On Sat, Nov 15, 2014 at 10:34 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
> Furthermore, this does not very easily facilitate multiplexing multiple
> “ports” on the same websocket listener. In other words, it makes it somewhat
> difficult to have multiple different nanomsg REQ/REP consumers on the same
> websocket end point. While this may not be a big deal, I’d rather be able to
> have a single websocket listener at a well known port (80), that can then
> hand off to sub-handlers based on the websocket headers. This is indeed what
> websocket was designed for.
>
Well, I don't believe it's good idea to make such ad-hoc things in one
transport. For example it does solve the problem when single process
want's to listen single port, but doesn't solve when there are
multiple processes. So this case should be solved by one of the
following:
1. Generic tunelling implementation. Where multiple nanomsg sockets
are tunelled through single, probably PAIR socket. It's useful not
only for port sharing, but for compression, encryption, etc. And not
only for websocket transport.
2. A gateway approach a/k/a zerogw or mongrel2. The process that
accepts connections, authenticates, does DoS protection, and tunnels
messages to nanomsg network.
--
Paul
Other related posts:
