[nanomsg] Re: websocket mapping
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2015 19:14:04 -0800
> On Feb 3, 2015, at 6:45 PM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx> wrote:
>
> > "The are no extra frames issued during websocket setup"
>
> Cool. Perused `ws.go` and `wss.go`, and it seems like a sane implementation.
> Though, do we need a version? e.g., `rep.sp.0.nanomsg.org
> <http://rep.sp.0.nanomsg.org/>`
I am disinclined at this point. I’d suggest we could add that later, “sp1”, or
“1.sp” or somesuch. I wouldn’t bother now.
>
> > "I see some debate for how a multilayer protocol should be represented into
> > a DNS-like string"
>
> Agree, but again, we're kinda limited to how egregiously we can overload the
> `Sec-WebSocket-Protocol`, assuming all negotiation happens in first frame,
> and given Javascript API and browser support only allows setting this one
> header! RFC 6455 does allow multiple protocols to be specified in order of
> preference, meaning it's possible to place our own semantics on an array of
> protocols specified by the connecting client -- though, the server still must
> select only one and return this as a response. Though... thinking aloud...
> the server could echo/ACK those additional protocols as separate headers….
So the DNS based name is actually what RFC 6455 *suggests* to avoid name
collision. Of course, your sub-sub-protocols are not part of the WebSocket
layer negotiation. To be honest, there’s not really a great way to do deal
with that. I’d be happy to say that implementations that wanted to stash
another value here can do so — they won’t be wire compatible with other
websocket SP implementations, but that may be a non-issue. (In fact, in Mangos
I could trivially make these values tunable parameters, but its also trivial to
derive a new “transport” that just expresses a different value here.)
There’s sadly not a great way to hierarchically represent the embedded sub-sub
protocol in websocket. Its a limitation of the WebSocket APIs. Its too bad
because there is a potential richness in the actual HTTP headers that we simply
cannot access, or rather *we* could but our most likely peers wouldn’t be able
to.
At the end of the day, the *only* rational reason to use websocket here that I
can see is because you have no choice because you need to speak to browser
clients, or need to transport things over HTTP because of plumbing (firewalls &
NAT proxies) that won’t pass TCP unmolested. In every other way, I think
websocket is a poor fit for nanomsg.
I’ve also made the changes to nanomsg (and verified interop), as well as
updated the RFC, here:
https://github.com/gdamore/nanomsg/commit/60ef9d307ed9788ea93f2d02a8857c1955140f21
<https://github.com/gdamore/nanomsg/commit/60ef9d307ed9788ea93f2d02a8857c1955140f21>
- Garrett
Other related posts:
