[nanomsg] Re: websocket mapping
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2015 20:16:05 -0600
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
>> <mailto:drew@xxxxxxxxxxxxxxxxxx>> wrote:
>>
>>
>>> On Feb 3, 2015, at 2:57 PM, Garrett D'Amore <garrett@xxxxxxxxxx
>>> <mailto: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:
