[nanomsg] Re: WebSocket transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 15 Nov 2014 14:24:10 -0800
> On Nov 15, 2014, at 1:22 PM, Paul Colomiets <paul@xxxxxxxxxxxxxx> wrote:
>
> 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:
Well, I’m assuming that you need to use either different TCP port numbers (or
addresses), or use a two tier hand off, if you want to work with separate
processes. (Imagine a gateway process that does the accept, a little bit of
logic, and then forks the actual actual application, choosing to exec() the
appropriate app based on the URI Path element.
>
> 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.
I view tunneling as a less-than-wonderful approach in the general case, but
probably quite useful certain problem sets. I’d leave this well outside of the
protocol specification though, and instead leave it to applications.
>
> 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.
Instead of “tunnels”, think, *hands off*. E.g. the fork/exec of the actual
proper program, once the websocket connection is established.
I see a couple of ways to approach the problem, depending on the deployment,
and I’d like a solution that doesn’t prevent any them:
a. a single program that binds to a specific TCP port, but uses websocket
instead of TCP. (Presumably the main / only reason for this instead of just
raw TCP is to make it easier for JavaScript clients to interface to it.) This
is the most simple kind of deployment, but doesn’t share a single inbound TCP
port with different applications.
b. A server that looks at the URI path element, hands off to a generic
websocket helper program (or module) that groks nanomsg and our headers.
c. Like “b” above, but do the handoff on a “sub-protocol” level. Whether
sub-protocol needs to be available in something other than the URI Path
probably depends upon the server. I don’t know what typical servers offer in
terms of configuration to select different websocket “helpers”. TBH, I
generally avoid “web programming” (server or client!) like the plague, so I’m
sure other people will have a clearer picture here.
- Garrett
>
> --
> Paul
>
Other related posts:
