[nanomsg] Re: websocket mapping

  • From: Jack Dunaway <jack@xxxxxxxxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Tue, 3 Feb 2015 20:45:14 -0600

> "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`

> "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....

Best regards,
Jack R. Dunaway | Wirebird Labs LLC

On Tue, Feb 3, 2015 at 8:16 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
wrote:

> Ah.  I see.  I did not see the thread abolishing the follow-on frame.  I
> think that is less objectionable.
>
> My only comment about the revised proposal is that I see some debate for
> how a multilayer protocol should be represented into a DNS-like string.  In
> particular, whether it should “be” the protocol that it is on the outer
> layer, or whether it should “be” the whole onion.  But, since I am the only
> implementation of multilayer protocols, the question is at present academic.
>
> I still think we have a philosophical dispute here:
>
> sort of like people should be able to glue random sockets of any type
> together without any checks whatsoever.  *That* I’m fairly opposed to,
> since the message headers (the SP headers sent with each message) have to
> be interpreted differently for different SP protocols.
>
>
> But in my mind this is much more easily solvable, since it’s not
> especially hard to produce an implementation that is configureable on the
> question of what checks are performed.
>
> If somebody is interested in paying the price to get better checks for
> configuration errors I don’t begrudge them; but I will flip the bit that
> keeps the tax out of my hot path.  That sort of thing is technically
> a “deviation", but I don’t think it’s large enough to argue over.
>
> On Feb 3, 2015, at 7:54 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
>
> On Feb 3, 2015, at 5:13 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
>
> On Feb 3, 2015, at 2:57 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> It is a performance tax. But only during connection establishment.
> Compared to the tcp setup it probably is in the noise.
>
>
> Well I agree with you, mostly, about the TCP case.  The TCP overhead is
> zero or near-zero.
>
>
> Actually… its kind of each side has to send one extra 8-byte message at
> the start of initiation.  Definitely *not* zero.  And each side waits to
> receive the others start frame as well.  These happen in parallel, so it
> isn’t lock step, but it definitely adds a little latency to the TCP setup.
>
>
> However, what we are talking about with WS is a case where it is
> definitely nonzero, and is a full roundtrip, at least.  So in that case the
> cost-benefit is much different than it is for the TCP case.
>
>
> Wait a minute… I think you misunderstand me, or are not caught up.  I
> *agreed* with you here.  The are no extra frames issued during websocket
> setup.  (That was my older proposal, which I agree was broken.)  The only
> thing done in the current version is to more tightly specify the
> Sec-WebSocket-Protocol header issued in the HTTP request.  Again this is
> setup time, but frankly you can’t avoid it because the overhead (apart from
> the size of the header being slightly longer) is already covered with the
> HTTP negotiation — its non-avoidable and builtin to websocket.
>
>
> Anyway, if anyone has any complaints about this approach, I’d like to hear
> it.
>
>
> I’ve made several complaints.  You may not find them to be valid; there’s
> not much I can do about that, except deviate for my implementation.  That’s
> essentially the situation I’ve resigned myself to on several points, but
> unfortunately the list seems to be growing.
>
>
> Again, I think you’re not following me here.  Please go back and read what
> I’ve written.  There is no SP specific negotiation phase, we’re just using
> the HTTP header for Sec-WebSocket-Protocol.
>
> Now, I did see you seem rather opposed to even that level of check — sort
> of like people should be able to glue random sockets of any type together
> without any checks whatsoever.  *That* I’m fairly opposed to, since the
> message headers (the SP headers sent with each message) have to be
> interpreted differently for different SP protocols.
>
> - Garrett
>
>
>

Other related posts: