[nanomsg] Re: websocket mapping
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 31 Jan 2015 13:26:13 +0100
No opinions? My mangos implementation is now in the websocket branch of mangos
on github.
I'm going to make a clone of nanomsg with the same protocol changes.
I would be very interested in feedback.
Sent from my iPhone
> On Jan 30, 2015, at 1:36 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> I’ve started (and mostly completed) a websocket mapping of mangos. I started
> hoping to make it compatible with nanomsg’s mapping as specified in the
> websocket nanomsg RFC, but as I got into details, I discovered somethings
> about this RFC that I think are a big mistake.
>
> The biggest problem is that we are relying on the Protocol field to express
> which SP topology is used. This results in at least these problems:
>
> a) The transport needs to know the name of all protocols, which does not
> facilitate expansion and badly breaks the layering abstraction.
>
> b) Some implementations don’t make it easy to pick up on the values used
> by the server and client protocols. For example, the Go websocket
> implementation lets the client specify the protocols it want(s) to use, but
> it cannot see what the advertised protocol on the server side is.
>
> c) Its likely that some implementations are going to have trouble when
> x-nanomsg-req != x-nanomsg-rep — i.e. we cannot have mismatched protocols.
>
> I think problem “a” could be easily fixed by using numerics encoded as
> strings, but problems b & c are more severe — I think they come about from a
> basic design philosophy difference — in websocket I think the intention is
> that the ultimate “negotiation” is done on the server side, based on what the
> client claims to desire. Its not really a two-way neg like SP is.
>
> Thinking about this quite a bit, I’ve decided that the best thing would be to
> change the mapping as follows:
>
> 1. The protocol field should just be the value “x-nanomsg” — without any
> reference to the subprotocol.
>
> 2. A message exchange very much like what is is done for TCP should be done
> at when the connection is established. That is each side should send a
> “header”, and then should receive and validate the peer’s header.
>
> 3. Given that some websocket clients really need to deal with text values
> (e.g. older web browsers can only send strings), the content of the header
> should be as follows:
>
> “SP0:<protocol>:0” — these are ASCII characters forming a string. The
> SP0: indicates SP version 0, the <protocol> is a numeric protocol (for
> example PUB would 32, and SUB would be 33) represented in decimal ASCII, and
> the :0 is reserved for future protocol enhancements (like the reserved fields
> in the binary header exchange). So for example, a REQ client would send
> SP0:48:0 and a REP server would send SP0:49:0
>
> This should facilitate working with more websocket implementations, although
> to be clear the header exchange would prevent using this library to talk to
> arbitrary websocket services — peers would only match and peer each other if
> they are running the proper SP peer protocol. I see almost no value in
> attempting to make nanomsg a general purpose websocket library.
>
> Thoughts?
>
> - Garrett
>
Other related posts:
