[nanomsg] Re: WebSocket transport
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 15 Nov 2014 07:27:43 -0600
Hello,
Congrats to Jack & all. I know from experience that introducing new
protocols/transports is quite an achievement. The next time Martin’s in ATX,
we should grab a beer/coffee (and same Jack, we should have done that awhile
ago since you’re local)
I have a few implementation remarks, but I’ll hold while we discuss design per
your instruction.
> Should WebSocket transport allow to use different opcodes (i.e.
> binary vs. UTF messages)?
I think the question we face here is a fundamental challenge to the original
design of transports: a nanomsg transport is a dumb pipe over which any kind of
content can go over any type of protocol. However WS as specified by W3C
doesn’t fit well into nanomsg’s mold; it’s a thing that wants to be
content-aware.
If there is a real use case and someone willing to do the work then I certainly
think the idea of content-aware transports should be explored. I’ve long been
a critic of the protocol/transport model as too simplistic.
However in this case I think it is difficult to arrive at a simple proposal
because with the scalability protocols sitting between the application and WS
transport it’s not clear to me how a restriction on (for example) UTF-8 content
arriving through an arbitrary scalability protocol could even be enforced. So
I’d like to hear more about the use case for using WS opcodes in nanomsg.
> 2) Should SP type IDs be in text format (as is the case now) or should
> they just be numbers (as in all other transports)?
I would prefer numbers, since reserving a protocol number seems hard enough ;-)
> 3. Is there a need for some kind of special termination handshake?
I think this is an application-level feature, or at least not a feature that’s
specific to WS transport.
> On Nov 15, 2014, at 6:08 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> Great news!
>
> Jack Dunaway have implemented new transport in nanomsg, one layered on
> top of WebSockets.
>
> It works pretty much the same as all the other transports:
>
> nn_bind (s, "ws://127.0.0.1:80");
> nn_connect (s, "ws://127.0.0.1:80");
>
> Big kudos to Jack, given the complexity of the task!
>
> However, note that transport is currently marked as "THIS IS AN
> EXPERIMENTAL FEATURE. DO NOT USE. THE FUNCTIONALITY IS SUBJECT TO
> CHANGE WITHOUT NOTICE."
>
> For those interested in the topic, we should now decide on the details
> of the transport.
>
> My suggestion is to discuss the protocol first and move to API and
> implementation issues afterwards.
>
> The currently used protocol mapping is briefly described here:
>
> https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-websocket-mapping-01.txt
>
> Some points to discuss:
>
> 1) Should WebSocket transport allow to use different opcodes (i.e.
> binary vs. UTF messages)? If so, should it be done on per-connection
> or per-message level? Also, if we allow for UTF-8 messages, how would
> we encode SP headers?
>
> 2) Should SP type IDs be in text format (as is the case now) or should
> they just be numbers (as in all other transports)?
>
> 3. Is there a need for some kind of special termination handshake?
>
> Thoughts? Insights?
> Martin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUZ0JPAAoJENTpVjxCNN9YCIsH/jFm5EgB2DP/zL0tho0vIUFH
> QolWpcN6npGgdio2xwoUCs46mn6tYxZ3eexC8lIyPRBuobZwf0TH/3fHI1yAappM
> c/TYneGs9U7ve7eYnPU+LY/MX//3eUEql3Cm9e5ObaSpx0Vka21Cyb1c3cMz1EwM
> Sx/16/Ib+MQLiUIkEWrnwbMA1bIBtp/ljECz69Gsksapk3h/5vgZUBvCHC/+i9Et
> rhCM96ZYIhqUYcY1WDWGhh7NKjtluhSCsDK0Y0YaGJRfSF/ROYODGo3Qj+sSQWcM
> yjc53BWH02h4H/nqc/8OGfX2S4iu99DaQH/lgAJKz6rzDXOKUjpcMQQW3s7KhsA=
> =FZOj
> -----END PGP SIGNATURE-----
>
Other related posts:
