On Fri, Dec 12, 2014 at 12:02 PM, Fraser Adams < [email protected]> wrote: > > Yup pretty much exactly as Rafael says. > > If you are using the Qpid Java Broker you need to tweak the config.json in > qpid-work, basically you need to add something like the following to the > "ports" array (if you leave out the "id" I think a proper one should get > created): > > { > "id" : "7f44acca-5de9-4cab-a167-8a1ef7e4119f", > "authenticationProvider" : "passwordFile", > "name" : "AMQP-WS", > "port" : "5673", > "transports" : [ "WS" ] > } > > Which will activate the WebSocket transport on port 5673 > > If you are using the C++ broker there is a little Node.js WebSocket->TCP > Socket proxy provided in: > > qpid-proton/examples/messenger/javascript > > called simply proxy.js > > If you fire that up it will accept a WebSocket connection and connect to a > TCP socket > > ./proxy -h > > will show the options. > > In that directory there's a little send.html demo but it should be pretty > easy to do receive too. If you look at recv.js that's set up as a "server" > ( var address = "amqp://~0.0.0.0";) but if you were to do say: > > ./recv.js amqp://0.0.0.0/queue > > that would receive messages off a broker - assuming that you had a queue > called queue and you had enabled the Java Broker WebSocket transport or had > the proxy running :-) > > > Also (and this *still* bites me :-[ ) be careful of the ports. You > normally use 5672 for AMQP, but that's the TCP transport, the proxy.js > defaults to listen on 5673 and sends out on TCP 5672, so you'd generally > need to do: > > ./recv.js amqp://0.0.0.0:5673/queue > > > so basically I've just done: > 1. open a console and do qpidd --auth no > 2. do qpid-config add queue queue > 3. open another console and do (in qpid-proton/examples/messenger/javascript) > ./proxy.js > 4. open another console and do (in qpid-proton/examples/messenger/javascript) > ./recv.js amqp://0.0.0.0:5673/queue > 5. open another console and do (in qpid-proton/examples/messenger/javascript) > ./send.js -a amqp://0.0.0.0:5673/queue > > It should be fairly easy to hack around with send.html to pull in the > behaviour of recv.js > > > Be aware that the proxy.js doesn't have much in the way of error handling > yet if you use the proxy and qpidd and qpidd dies your client won't see it. > It's on my TODO list, but I've been tied up an a whole bunch of family Xmas > related things lately, so my weekends of coding have been a bit disrupted > :-D
It should be *slightly* more robust now. I fixed it so that it wouldn't fall over when you abort the websockets connection (e.g. from doing a page reload or something). 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
