[nanomsg] Re: WebSocket transport

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sat, 15 Nov 2014 12:34:57 -0800

I looked at the draft RFC finally (not code yet).

TBH, I don’t particularly like encoding nanomsg socket information here.  Its 
not a huge deal, but it means writing more websocket specific handling code 
than would otherwise be necessary, and it means that the websocket transport 
winds up being “aware” of the nanomsg protocol — which means when adding a new 
protocol/pattern, the transport is going to have to be fixed.

I don’t particularly like that.

Furthermore, this does not very easily facilitate multiplexing multiple “ports” 
on the same websocket listener.  In other words, it makes it somewhat difficult 
to have multiple different nanomsg REQ/REP consumers on the same websocket end 
point.  While this may not be a big deal, I’d rather be able to have a single 
websocket listener at a well known port (80), that can then hand off to 
sub-handlers based on the websocket headers.  This is indeed what websocket was 
designed for.

Also, it seems that there is no value supplied for the URI.  So I’m not sure 
how we specify the “path” (URL resource) in a WS url.

So, I’d suggest the following changes:

1. Sec-Websocket-Protocol field just becomes a single “x-nanomsg” value.

2. An additional websocket header be added to indicate a “subport” number.  
(Note, that this suggests that we have kind of two port numbers for websocket 
URIs,  the first being the actual TCP port which should default to 80, and the 
second being the subport number.)  Maybe the port number becomes an “argument” 
passed to the path.  (Hmmm… maybe instead this should be part of the PATH used 
in the websocket exchange?)

3. The first binary bytes exchanged in the websocket stream should indicate the 
nanomsg protocol, the same as for TCP streams. 

In fact, really, the simplest way to think about websocket I think, is as a way 
to connect the initial TCP streams between the applications, using a single 
well known rendezvous. 

One drawback (or benefit, depending on your view — I take the latter) to the 
approach I suggest is that using a stream of binary payload bytes means that 
the websocket connection cannot be used to talk to other arbitrary websocket 
services.  This is probably a good thing, as it prevents accidental mis-matched 
protocols.  (I know others here have expressed different opinions.)

  - Garrett

> On Nov 15, 2014, at 6:07 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Drew,
> 
> 
>>> 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.
> 
> My position on this that the transport should just be a dumb pipe, all
> messages being binary. After all, nanomsg API sends & receives binary
> blobs. Jack's opinion, I think, differs.
> 
>>> 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 ;-)
> 
> Reserving both numbers and names is somewhat redundant, but, OTOH, not
> prohibitively so. So, if there's a good reason to do that, we should.
> 
> However, so far the only reason I see is that WebSocket protocol
> requires text in this field and using strings like "SP-17" is a bit ugly.
> 
> Martin
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJUZ14YAAoJENTpVjxCNN9YOMoH/3Q5ASO5MMndfS797n0zVEr2
> vl7V6EkNk2vq/POnceqM3k+SDWBCAhflTyg72iA/dTWzzV6712JjeCXR7EX7Gm91
> gxc/ZcJ5xzsugNQClku6G4VjdjNv6pYn+kGF+XePWipk0Yq8VvmrtnLUUgQKmdFa
> /KSreaXJR6nXT+pQVcRyWryjagJ+xuL1+39y3UGcoULwhVSXvFnte00ZgPjBUA6X
> k75zTYifHgF+nhTeeTRvQHWrs8OxbUFPabUg4ZGsiaIrPNViMqkf2YYK38ju2p+y
> BOAIQMjdnd1ft/VhUF5v7NmZDMB6WVjTJ0LDgeFISJWCs88hBWPecU96MZQcArA=
> =H+es
> -----END PGP SIGNATURE-----
> 


Other related posts: