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?
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.
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 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.
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:
LINK_FLAGS "-s \"EXPORT_NAME='proton'\" -s
\"WEBSOCKET_SUBPROTOCOL='AMQPWSB10'\" ${EMSCRIPTEN_LINK_.......
I think that if you take out the
-s \"WEBSOCKET_SUBPROTOCOL='AMQPWSB10'\"
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.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
