[nanomsg] Re: websocket mapping
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2015 17:54:33 -0800
> 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
>> <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:
