[nanomsg] Re: WebSocket transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sun, 16 Nov 2014 09:15:26 -0800
I think we are on the same page. As to writing the proxy thing in go...
Probably it would work. I haven't looked yet.
Sent from my iPhone
> On Nov 15, 2014, at 11:38 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 16/11/14 07:42, Garrett D'Amore wrote:
>
>>> There are lots of way to handoff from a gateway process to some
>>> other nanomsg service; I don’t necessarily think that this
>>> handoff will occur in the libnanomsg API — or at least not in
>>> what we have today; it would use some kind of new API or a
>>> totally separate implementation, I think.
>
> Yes. If the multiplexer is to be shared by all the processes on the
> box, it has to be a separate process. I wonder whether it's doable in
> Go. Is there support for AF_UNIX/SCM_RIGHTS?
>
>>> In the meantime, the critical things to think about:
>>
>>> 1.) What do service addresses look like… URIs path components
>>> work fine for me, but we should have a spec for this if we are
>>> going to have it mean anything. And even if not, we should say
>>> so.
>
> Yes. I think we could think of something generic enough to cover the
> simple case (with no multiplexer) and put that into the spec. E.g.
> "URIs are treated as opaque strings. Different strings correspond to
> different SP endpoints."
>
>>> 2.) I remain opposed to the idea that we would encode string
>>> protocol names in the websocket handshake — as much as possible
>>> the transport layer should have no knowledge of the actual
>>> protocols. Keep the layer separations clean.
>
> The "stand-alone multiplexer" scenario seems to support this idea:
> Muliplexer handles the WebSocket handshare in SP-agnostic manner (it
> could even work with non-SP protocols!) then hands the connection to
> the SP-enabled process. The process does initial SP header exchange
> afterwards.
>
>>> 3.) As much as possible, once the connection is established, I
>>> think websockets should look and act like established TCP
>>> streams from the perspective of the protocol. I’d use the same
>>> framing and early negotiation (including negotiation of the SP
>>> protocol and version) using the same binary packets.
>
> One caveat: There's no "bytestream" concept in WebSockets. We should
> just map WebSocket framing to delimit SP messages. Oherwise agreed.
>
> Martin
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUaFSRAAoJENTpVjxCNN9Y3QgH+gPHbI89jVeknWC039t3LE1b
> sMSzJE/y2YvZ+44oK0LZTl6pV6NlKIXeWLKTfHWgI4ALKeRzR5QbrgeCpKf0UP4b
> JpRrStSmjg7rifChCgFiHRZz41pxGZ7u+brgTfQ/seBCjkfMRIwTmXI5szseFgcS
> PdDOui48LQiTUbMv7Btgu6KgVbyTjIUS4qcTs9iYKOXYL+Xn0JsaXkJvkaRXfJWa
> CTbpfyasQdCJL+uUwkB5MSOcI7egxbRglkn5VP7+3FlbcmgexWL+Jo+WPBIz7l7q
> owojkeWj38iJSPKH79xSDsVHjURA3owFJfFOf9RBcpAPthTsh+hfJe1eGMVomys=
> =MqbX
> -----END PGP SIGNATURE-----
>
Other related posts:
