[nanomsg] Re: websocket mapping
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2015 11:35:25 -0600
> On Feb 3, 2015, at 10:21 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> I don’t view this as an “Evil Bit” check — its more like an attempt to
> protect users from misconfiguration. Clearly there is nothing here to
> prevent malicious use. But part of our philosophy is that you only match
> endpoints with sane peers; naive users/developers may try to build
> nonsensical and unsupportable configurations without this sort of validation.
>
An analogy can be made here to assert. Most sane people have asserts on during
development, and then they turn them off in production. This is because while
asserts provide useful information when one is initially developing or
configuring software once the thing is known to be stable they are a
performance tax.
The handshake is an assert that cannot be disabled, because it is baked into
the RFC and everybody must implement it in every environment. If it was a
“debugging extension” then that would be one thing.
Further, if this feature were *truly* designed to alert users about
misconfiguration then it would be sufficient to bundle the handshake into the
first few application-level messages and simply “optimistically assume”
everything is alright until that time that it’s complete. Getting strict about
it, that is, delaying application messages while the handshake is worked out,
is not an implementation designed around merely preventing misconfiguration.
It is much stronger in its guarantee than that problem requires.
> Note that SP is *not* as I see it oriented to making low latency
> *connections*, but rather towards operating at lower latency while already
> connected.
I’m not really sure what to say here. I suppose the canonical response is to
fork.
Other related posts:
