[nanomsg] Re: ws transport
- From: Jack Dunaway <jack@xxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 29 Nov 2014 00:29:59 -0600
> I would love to using web sockets with nanomsg, but
> it seems like we're asking for trouble in the long run by muddling two
> totally different things.
Would you further elaborate upon "would love to using", "asking for
trouble", "muddling", and "totally different things"? Specific insight will
help spur and focus development -- thank you!
Best regards,
-JRD
On Fri, Nov 28, 2014 at 4:21 PM, David Beckwith <thirdreplicator@xxxxxxxxx>
wrote:
> What is the advantage and/or rationale of supporting WebSocket in the
> nanomsg library? It seems to me that it should be in a totally
> separate library. I would love to using web sockets with nanomsg, but
> it seems like we're asking for trouble in the long run by muddling two
> totally different things.
>
> On Thu, Nov 27, 2014 at 3:08 PM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx>
> wrote:
> >> Thinking about it, can't we at least formally separate the ws library
> >> (say by putting the files into a dedicated folder) from its sp mapping?
> >
> > I tend to support keeping ws:// in mainline, and paring it to fit the
> spirit
> > of nanomsg, rather than separating as a full-fledged library. For
> > simplicity.
> >
> >> Autobahn
> >
> > Autobahn is configurable such that we can select only relevant tests via
> > JSON configuration. I would encourage continuing to use it for nanomsg
> ws://
> > testing by just just removing the UTF-8 validation tests, especially for
> its
> > comprehensive and creative recipes simulating control frames, header
> > framing, fragmentation, masking, chopping, fuzzing, etc.
> >
> > Assuming SP is communicated via HTTP header, rather than 8-bytes
> > nanomsg-TCP-style, we could still use Autobahn; else, Autobahn TestSuite
> > would require customization to test nanomsg.
> >
> >> Well, my gut feeling here (but one backed by a decade of protocol
> >> design) is that it's never a good idea to coalesce two adjacent layers
> >> in the network stack, however convenient that may seem at the first
> >> sight. That kind of thing blurs the distinction between layers, over
> >> the time it introduces more and more tight coupling between the
> >> layers, results in hacky code etc.
> >
> > NN_PIPE_PARSED is a case study! (cue Drew :-)
> >
> > I agree with you here, full coalescence would yield all manners of
> coupling
> > that hurt usability and extensibility for all SP/transport combinations.
> For
> > clarity, I'm not suggesting or supporting fully coalescing SP with WS --
> but
> > rather, leveraging the protocol's existing mechanisms that are designed
> for
> > that purpose. I guess this means I endorse intentionally overlapping
> layers
> > where it makes sense, where 'coalescing' might not be the right word for
> > what we're trying to do here.
> >
> > Another example of this leverage is the framing of messages. SP messages
> > sent over TCP from nanomsg defines a header that includes message size.
> The
> > WebSocket protocol does not need to mirror this same header in addition
> to
> > its own, because the current SP hdr is satisfied by the requisite
> WebSocket
> > message header framing. (Though, I prefer the SP protocol of fixed-width
> > rather than variable-width length!)
> >
> > This same design strategy of utilizing the transport's existing protocol
> is
> > what I suggest we apply to the SP swap as part of the WS opening
> handshake,
> > not following it. The transport's existing handshake provides facilities
> for
> > embedding higher-layer protocol metadata that could steer the outcome of
> the
> > connection.
> >
> > Again, this is also for the sake of debuggability, discoverability, and
> as
> > another heuristic for intermediate HTTP routing.
> >
> > Finally, admittedly, my very first push of the ws:// implementation has
> much
> > more coupling than is healthy, but for two reasons -- 1) ship early!,
> and 2)
> > as monolithic, contained starting point that could then be properly diced
> > and pared and reticulated into nanomsg. Said another way, that first
> draft
> > implementation might appear to coalesce the layers, but that's a
> byproduct,
> > not an endorsement, and needs fixing! :-) Conversations like this help
> steer
> > which parts should remain overlapped (like this header swap) and which
> parts
> > should be split/nixed (like L6 UTF-8 validation).
> >
> >>> 4) Canonicalizing text representation of SPs in
> >>> sp-protocol-ids-01.txt in addition to numeric ID
> >>
> >> Yes, if we really want to coalesce the layer, but I still think it's a
> >> bad idea.
> >
> > Are you more opposed to framing the SP in the HTTP header altogether, or
> > more about simply the naming "SP-31" vs "x-nanomsg-rep"? Let's tackle the
> > framing first, and then move to the content of that framing.
> >
> >>> 1) Introducing a Close Handshake to nanomsg. Even though it is
> >>> "application level", and certainly not "transport level", it
> >>> widely-applicable enough to consider adding to all transports.
> >>
> >> As already asked above, what's the use case?
> >
> > 1) Protocol violation. I like how WebSocket endpoints MUST fail peers if
> the
> > protocol is violated, in order to maintain their own health. A failed
> > connection in nanomsg could manifest as an errno returned by any
> operation
> > performed on a socket that was failed by the remote.
> > 2) Stopping automatic reconnect attempts.
> > 3) Generally applicable for connections not intended to be persistent
> >
> > It's possible that I'm overlooking the TCP close handshake's ability to
> > handle these things.
> >
> > Best regards,
> >
> > Jack R. Dunaway | Wirebird Labs LLC
> >
> > On Thu, Nov 27, 2014 at 4:09 AM, Martin Sustrik <sustrik@xxxxxxxxxx>
> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 27/11/14 10:49, Martin Sustrik wrote:
> >>
> >> >> 3) Using Autobahn TestSuite as a fuzzing tester. This requires
> >> >> the transport be able to set the resource path in the URI on
> >> >> connection.
> >> >
> >> > Ok, so here we deal with the problem of coalesced layers.
> >> >
> >> > Imagine you wrote a full-fledged ws library and then used it in
> >> > nanomsg to provide ws transport.
> >> >
> >> > You could test the library using standardised ws test suite and
> >> > the mapping to sp using nanomsg's test suite.
> >> >
> >> > Unfortunately, we don't have the two layers separated. Thus,
> >> > there's no component for ws test suite to test. Testing the full
> >> > featureset of ws using nanomsg is impossible in the same way as
> >> > using ws test suite cannot be used to fully test TCP (consider TCP
> >> > OOB data and such).
> >>
> >> Thinking about it, can't we at least formally separate the ws library
> >> (say by putting the files into a dedicated folder) from its sp mapping?
> >>
> >> The API of the lib would deal just with the framing, e.g.
> >>
> >> void ws_create_request (void *buf, size_t buflen, conat char *host,
> >> const char *resource, const char *protocol);
> >>
> >> Maybe this "lib" can then be tested with Autobahn?
> >>
> >> Thoughts?
> >> Martin
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.11 (GNU/Linux)
> >>
> >> iQEcBAEBAgAGBQJUdvhFAAoJENTpVjxCNN9YCYEH/3eqf98MxwzMnu1FGwK/rTc5
> >> C1BZZ67pfyTFZcQwGC0CbuARhCJsjW6SNbwfObcc6YuYdyeyAzSAaT0VfsGjuygz
> >> UR8Br0nJHunSmq6bdb+X0ukE6vUWCNqPhQb9AGYJMWUCJusiggmGDWh5CYK1dVP6
> >> /xPq5Y2IHtVN4wZMA4+hTjd+8qxQ9dMXcM5nc35y0FBRaJF0QKEp19RRf5ac0q1o
> >> sZE/KbfXRXXhG+h8bSRujN+NLY8wkvMRUuQoKmCScNNfJgI/YFyXcPAgPyKprQ5R
> >> OoVdqsQUUC1kwZA1ZVXH49SqMaQXkkkKpbLcNSYSAlpnowDKZxGq1u/39BO7QE4=
> >> =UnUR
> >> -----END PGP SIGNATURE-----
> >>
> >
>
>
Other related posts:
