[nanomsg] Re: websocket mapping
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2015 08:21:50 -0800
> On Jan 30, 2015, at 12:21 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
>> > "I don’t think SP handshakes in general are useful"
>> What's the alternative? Encode this information per-message, rather than
>> per-connection?
>
> Per-message is certainly preferable, but more broadly I don’t really believe
> that there is a problem to be solved here.
>
> Allegedly negotiation exists to provide the user an error message if the
> protocols are incompatible. But fundamentally nanomsg is always used with a
> higher-level “application protocol” that logically encapsulates the version
> of nanomsg (and the version of its protocols) that the application uses. It
> is of no comfort, when App 1.0 communicates with App 2.0, that they both use
> the same version of REQ. You can’t solve the problem at nanomsg layer.
>
> More broadly I think writing “if (message [0] != MAGIC) return error;”
> increases the chance that invalid messages are not robustly handled, and that
> errors in handling them will not be detected under ordinary circumstances.
> Writing that code is like writing code that checks for the Evil Bit
> <https://en.wikipedia.org/wiki/Evil_bit>. It is at best useless and at worst
> dangerous.
For connection setup, its really important that we have something to validate
that the protocol is what we intend. The reason here is that at the *SP*
layer, we have headers, and those headers are different for different
topologies. It would be bad to misinterpret a REQ header using SUB, or vice
versa.
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.
There is little value in this per-message for stream oriented protocols.
For UDP type messages, I think we ought to include this type of detail per
message. But that’s only because there is no connection establishment phase.
>
> I think there would be some value if protocols were versioned and there was a
> desire for one socket to support several old versions depending on what
> connecting peers purported to support. But I am not aware that anyone is
> actually doing that, and the people who are doing SP extensions are doing it
> in ways that specifically avoid that, for example by shipping entirely new
> protocols.
Well, the new protocols generally have different semantics. I think we’ve
talked about fixing some bugs in a couple of the protocols, and that might be a
good time to do the version update. The SP header does contain a version, but
I think that refers to the whole version of SP, rather than the version of a
subprotocol. To be honest, at this point in the game, its probably easier to
crank the protocol number.
>
> In spite of all that I am not really opposed to it if the cost is low. A
> byte here or there is nothing to quibble about. Where I start to have more
> serious problems is if we introduce additional roundtrips. Now we are not
> just doing something a bit silly, we are also being slow.
Agreed — especially if we had to do that frequently. For connection setup
(TCP) where connections ought to be long lived, it shouldn’t matter. However,
in the case of websocket, the extra packing turns out to be a pain in the arse
for JavaScript clients.
- Garrett
Other related posts:
