Re: Java Broker WebSocket support - now talks directly to JavaScript client!!

[Fraser Adams <fr...@blueyonder.co.uk>]

Hey all,
An update - mainly for Rob & Robbie, but Rafael and others might be 
interested too.

Adding:
{
     "authenticationProvider" : "passwordFile",
     "id" : "37b451cc-f4fb-4964-b352-21f5a474df73",
     "name" : "AMQP-WS",
     "port" : "5673",
     "transports" : [ "WS" ]
   }

To my Java Broker config.json enabled the WebSocket support to the Java 
Broker nicely and I've now been able to *directly* send messages to the 
Java Broker from my JavaScript port of Proton's "send" program by doing:

node send-async.js -a amqp://guest:guest@localhost:5673/test

I've now got to make things rather more idiomatically JavaScript via 
some binding code (what I've currently got is completely compiled via 
emscripten from my send-async.c/recv-async.c C programs).

The only tweak that I had to make was make sure that emscripten set the 
subprotocol to "AMQPWSB10" that was harder than it should have been for 
node because it uses the "ws" WebSocket library so needs
new WebSocket(url, {'protocol': 'AMQPWSB10'});

rather than just
new WebSocket(url, 'AMQPWSB10');

As a browser would need - and it took me ages to figure out the syntax :-D


I'll need to add a patch to emscripten to make the WebSocket subprotocol 
setup more configurable, but that's no bigee.



I guess that one thing to mention comes from a conversation between Rob 
and myself the other day. As it happens Rob's WebSocket server is quite 
"lenient" with respect to the draft AMQP/WS spec. and as it seems what 
I'm doing is not quite "compliant" :-)

What I'm doing is literally a compilation of proton-c and the posix 
driver.c writes out an AMQP byte stream in a buffer to a socket - and 
it's that buffer that gets written to the WebSocket. According to the 
conversations that I've had with Rob it seems that the AMQP/WS spec 
looks to make use of WebSocket framing. As I say I'm simply treating the 
byte buffers from proton-c as an opaque octet array.

In order to make things more compliant apparently proton-c will need to 
have a way to expose the *frame* transport. I guess that's worth a 
discussion at some point, but for now it seems pretty cool that Rob's 
"lenient" server copes with my "non-compliant" client :-D yay!!

Regards,
Frase


On 12/01/14 17:51, Robbie Gemmell wrote:
> I think that would give you an exception  due to two ports with the same
> name, but change the name and essentially yes. The broker will assign the
> ID if you start it up without one, yes, which is probably the best thing to
> do generally if adding things under its feet :).
>
> Sidenote: the easiest thing would probably have been to create the port via
> the UI, pick TCP or SSL explicitly, and then flip the transport to WS.
>
> Robbie
>
> On 12 January 2014 17:44, Fraser Adams <fr...@blueyonder.co.uk>wrote:
>
>> Hi Robbie,
>> Just trying to digest your comments below with respect to enabling Rob's
>> magical new WS support.
>> At the moment my config.json has:
>>
>> "ports" : [ {
>>      "authenticationProvider" : "passwordFile",
>>      "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
>>      "name" : "AMQP",
>>      "port" : "5672"
>>    }, {
>> ..........
>>
>> If I'm reading you correctly  if I do something like:
>>
>> "ports" : [ {
>>      "authenticationProvider" : "passwordFile",
>>      "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f19",
>>      "name" : "AMQP",
>>      "transports" : [ "TCP" ],
>>      "port" : "5672"
>>    }, {
>>      "authenticationProvider" : "passwordFile",
>>      "id" : "9e2707d9-10b4-4c3e-8439-cd6135419f1a",
>>      "name" : "AMQP",
>>      "transports" : [ "WS" ],
>>      "port" : "5673"
>> }
>>
>> that would give me AMQP over a TCP transport on port 5672 and AMQP over a
>> WebSocket transport on port 5673, is that correct - presumably if I omit
>> the "id" I'll get a proper one allocated too?
>>
>> Frase
>>
>> On 12/01/14 17:31, Robbie Gemmell wrote:
>>
>>> Despite what my last mail said, to do that I think youll probably have to
>>> edit the broker config by hand, as the support is there but isnt really
>>> exposed.
>>>
>>> Ports default to TCP if the transports attribute isnt explicitly
>>> specified,
>>> which it isnt by default, but if it was it would look like: "transports" :
>>> [ "TCP" ]
>>>
>>> To use WebSockets, change the TCP to WS.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org