[nanomsg] Re: WebSocket transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 15 Nov 2014 18:23:09 -0800
To be honest most of what I think we are driving at is a fundamental disconnect
in the design goals or purposes behind nanomsg and websockets. Websockets are
designed as a simple way for folks to tunnel a stream connection between a web
browser based client and a server on a fixed service point. If your server is
running in a separate process and is a full up process then you probably don't
need or want websocket.
If you "own" the tcp port and don't have to fork from a web server then the
problem is lots easier. In that case you can kind of treat websocket mostly
like tcp. But the question in my mind is what problem does such a
configuration solve better than existing tcp?
If on the other hand we are talking about a server that shares true http and
websocket on the same port then I think we are already beyond traditional
libnanomsg at least at the server.
You probably instead have something else that is kind of wire protocol
compatible but may just be a device layer to get to a more full SP topology
behind the device.
Sent from my iPhone
> On Nov 15, 2014, at 3:01 PM, Paul Colomiets <paul@xxxxxxxxxxxxxx> wrote:
>
> Hi Garrett,
>
>> On Sun, Nov 16, 2014 at 12:24 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>>
>> 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.
>
> Well, I believe we are doing everything to not to do this kind of
> things in nanomsg. E.g. we don't implement authentication of
> connection in handshake, but are trying to design security around
> encryption. But see below...
>
>>
>> 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.
>
> Sure, with little refinement: "leave outside of *this* protocol
> specification". But I think it eventually should be a standardazed
> tool for this.
>
>>>
>>> 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.
>
> Well for this to work we need more things:
>
> 1. We do not support fork(), which leaves nanomsg library operating in
> child. And presumably it's impossible.
>
> 2. We don't support accepting file descriptor instead of address, but
> probably should (it's useful for other things, like socket activation,
> or network namespaces)
>
> 3. We don't support getting file descriptor from nanomsg socket. And
> presumably should never do.
>
> It's also probably not very wise for performance (fork on every
> connect). It's also breaks every other aspect of design, I believe
> nanomsg assumes that connecting to the same address connects to the
> same process.
>
> --
> Paul
>
Other related posts:
