qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Javascript client for QPID C++ broker
Date Fri, 30 Oct 2015 11:03:12 GMT
Hi Rajeev
Not that I'm aware of.

What environment are your subscribers running on?

For browser based environments the answer is always likely to be that 
you'll have to use a WebSocket transport - browsers don't natively 
support TCP sockets for security reasons. I think that it's possible in 
"packaged app" environments on FF and Chrome but not a standard web app, 
it's not something I've looked into though.

If the environment is something like node.js that's another matter, it's 
entirely possible to support TCP sockets via the net package. TBH the 
biggest problem I'm afraid is time - I've been tied up on another 
non-Qpid related project for ages now  and haven't had any spare time to 
make this happen (the original goal I had was AMQP from a browser and 
getting it working nicely in node.js was a happy side-effect).

One *slight* complication is that the network code is somewhat 
abstracted - the way the JavaScript binding works is by using emscripten 
to compile Proton C to JavaScript so the C code is actually entirely 
un-modified and what happens is that emscripten network library 
intercepts the posix network (socket) API calls and translates them to 
WebSocket API calls. I actually contributed a fair chunk of the 
emscripten network code to get it to work with Proton and I think that 
the best approach to this problem is to add a bit more to it to get it 
to use the net module too, it's just a case of finding the time :'(

Actually getting it to work with the net module per se should actually 
be pretty easy, what has mostly kept me from having a go is that what 
I'd *like* to do is to have something that supports *both* WebSocket and 
TCP socket transports - I don't really want to have some compile time 
option, that's a lot fiddlier to do both in the emscripten code and with 
respect to the API - from the C perspective it's just using posix socket 
calls to how to go about selecting TCP/WebSocket needs a bit of thought, 
moreover for server side support I'd really prefer for that to be 
totally transparent - so I can connect from both a socket or WebSocket 
without having to tell the server, that's technically perfectly possible 
to do but I'd prefer to do it without having to implement my own 
WebSocket library :-D (I'm pondering whether it's possible to 
Monkey-Patch the ws library to expose a TCP socket if that's what has 
been used to connect).

I realise that you've been looking at the C++ broker, presumably you are 
aware that the Qpid Java broker actually has a native WebSocket 
transport? That should give you exactly what you need in practice 
depending on your other non-functional/deployment requirements. FWIW 
when I was writing this stuff I found no real difference using the Java 
broker versus the C++ broker with the proxy (the main performance factor 
was the performance of the JS engine - recent FF builds *rock* because 
the have asm.js optimisations). I'd say that the biggest issue with the 
proxy is that although I think it's fairly decent demo code it hasn't 
been kicked rigorously in an operational environment.

There was also some discussion earlier in the year about implementing a 
WebSocket transport in Proton (initially in the context of using it in 
the dispatch router) I don't know how far this has progressed, if at 
all. FWIW I think that having a native WebSocket transport in the 
brokers is the best way to go technically, whilst doing it in for 
node.js is worthwhile that's not going to solve the problem of allowing 
browsers to connect without a WS->TCP proxy and given that a broker is, 
well, a broker allowing all messaging clients to connect natively is 
somewhat the point really.

As an aside although there is a proxy I wouldn't say that it's 
necessarily "server-side" (though I guess it depends on your perspective 
of "server") what I mean is that if you are running in a networked 
environment it's perfectly possible to run the proxy on the client host 
such that the network calls coming off the client host are AMQP/TCP that 
might be semantics I guess, it depends on whether your issue with the 
proxy is a deployment one or whether it relates to perceived performance 
or latency issues - if it's running on the client host though you should 
avoid an actual network call and as I said above going via the proxy 
using the C++ broker performs at least as well as the Java broker using 
native WebSockets.

Sorry that's probably not the answer that you were hoping for. It's one 
of those things that I'm actually quite keen to do, but I doubt I'll 
find the time to look at it this side of Xmas.


On 29/10/15 20:11, rajeev verma wrote:
> Hi,  We are looking at pub-sub frameworks and are looking at  the Qpid C++ broker.We
are going to have a publisher written in C++ and subscribers that are Javascript.I looked
at the javascript bindings for Qpid, but that requires (server-side) proxy that translates
from AMQP to websockets.The proxy is an extra-hop that we'd like to avoid.Is there a way to
avoid the proxy?
> Are there any client-side javascript translators that can receive AMQP messages directly?Any
help appreciated...

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

View raw message