qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: heads up: javascript has landed
Date Fri, 12 Dec 2014 18:30:37 GMT
On Fri, Dec 12, 2014 at 12:39 PM, Fraser Adams <
fraser.adams@blueyonder.co.uk> wrote:
> On 12/12/14 17:08, Rafael Schloming wrote:
>> As an aside, I attempted to use a different web sockets to tcp proxy and
>> I got an error because the protocol wasn't "binary" or "base64". What exact
>> protocol are you using and how is your proxy transcoding to/from web
>> sockets to tcp? --Rafael
> Are you using websockify?

Yes, at least I was attempting to use it.

> The proxy isn't doing anything especially clever, the main code is in
> ws2tcp.js. It basically ignores the subprotocol when converting from
> WebSocket to TCP, though it allows you to specify a subprotocol when going
> from TCP to WebSocket. As for "transcoding" it's simply taking the raw
> octets off the WebSocket and putting them onto the TCP socket, i.e. it's a
> transparent proxy.

Hmm, so I hacked websockify to ignore what is specifed in the protocols
header and hard coded it first to use binary, and second to use base64.
Neither option seemed to work.

> To answer "what exact protocol are you using" presumably you mean the
> websocket sub-protocol? For that I'm using AMQPWSB10, which is the one
> specified by the AMQP JavaScript Binding. I'm pretty sure that the Java
> Broker WebSocket Transport requires that.
> It's also worth mentioning that because I've based the JavaScript stuff
> exactly on top of proton-c I'm literally pushing the same binary octets out
> over the WebSocket as would be pushed over a TCP socket - that's good in
> one sense as it makes proxying to TCP pretty trivial but the AMQP WebSocket
> spec IIRC makes use of the fact that WebSockets are frame based, so uses
> that instead of AMQP framing.

The WebSocket spec defines the websockets message payload to be exactly the
same bytes that constitute an AMQP frame, so if you concatenate all the web
sockets messages together as raw binary, you will get a valid sequence of
bytes to send over a TCP connection. The catch is that it goes further to
define an alignment requirement, specifying that every AMQP frame must map
one-to-one onto a websockets message. This complicates things for the tcp
-> ws direction of proxying because the proxy might do partial tcp reads
and end up fragmenting AMQP frames without realizing it.

> The Java Broker is tolerant of being sent full AMQP frames over a
> WebSocket and I personally think that is the best sort of behaviour. Making
> things "fully" compliant with the AMQP WebSocket spec is going to require
> changes to the underlying proton-c and that seemed overkill at this stage.

Given the way the spec is defined, what the javascript client is doing is
completely valid (I believe) and should be guaranteed to work with
anything. What the spec messes up is using a transparent proxy, i.e.
essentially forcing you to build/embed a web sockets implementation
directly into your AMQP endpoint (or build a custom proxy that understands
AMQP framing). I think the proper fix for this is to actually relax the
restriction in the proposed spec as it does more harm than good.

> Rob Godfrey mentioned that there was talk of adding an SCTP transport,
> which would also require some refactoring to separate out the framing, but
> IMHO at the moment I quite like it the way it is because *most* things want
> a TCP transport, so being able to proxy fairly transparently is currently a
> really useful thing.
> If you look in the CMakeLists.txt in qpid-proton/proton-c/bindings/javascript
> there's a bit that goes:
> I think that if you take out the
> bit it will default to specifying "binary" as the subprotocol, so would
> probably then work with websockify, but probably not then with the Java
> Broker.

Thanks, I might play with that if I get some time.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message