requirement: binary safety of frames

[mhaberler]

I think any framing/encoding of zeromq frames over websocket transports MUST handle frames binary transparent.

This is a requirement of using code. If the protocol layer can use a particular ws connection in binary-safe mode or not MUST not impact using code.

I think if JSMQ is not to be binary-safe, we could just as well encode a zeromq msg as a JSON object and be done with it. Actually base64 encoding non-binary-safe frames and tagging them as encoded, then sending the whole zmsg_t as a JSON object is an alternative option for the protocol. Not elegant, but workable.

[mhaberler]

Interesting related thread on ws binary safety: protobufjs/protobuf.js#176

current status hints: http://autobahn.ws/testsuite/reports/clients/index.html

[somdoron]

OK, I think we should support binary messages.

Few thoughts:

1. Part of the handshake the client should tell the server if we want to speak base64 or binary.
2. Anyway the JSMQ library will receive and send ByteBuffer (from https://github.com/dcodeIO/ByteBuffer.js), Uint8Array or ArrayBuffer?

[somdoron]

Also we need to change ZWS

[mhaberler]

I think we should consider this a peer-to-peer protocol where either side may request a certain feature; this will cover client/server but not exclude other scenarios. 'text only' would be such a feature.

I see two ways to go about it - either do an in-band handshake at connect time, or use the Websocket protocol name to have the Websocket upgrade phase negotiate a frame encoding. Using the latter means we would need variants of the protocol name (eg 'ZWS-base64-1.0' or 'ZWS1.0', the latter suggesting binary mode). But it would take care of negotiating the right setting already before connection established, and not require another protocol handshake which needs to be specified, implemented and maintained. And it would be extensible, for instance if one did a more efficient base128 encoding, that just can be offered during connect but it wont affect the peer side if not implemented.

How do you feel about protocol names with an embedded encoding type? I think it'd be the easiest route, and that handshake was intended to do exactly that.

That would suggest we specifiy the protocol per se as if links were always binary-safe, and have the protocol variant take care of encoding.

That opens the road to using normal binary ints to tag frames (actually I would use varints like in protobuf, because they would be single byte in the common case but have the option up to say 2^32-1 frame tags if needed).

Once the frame is constructed and if a text encoding is requested, the whole frame including headers is encoded (say base64 for now).

I would think this takes care of your firewall and browser version concerns?

JSMQ library: I dont an educated opinion here yet but will look into it. I would think the protocol should be specified in abstract terms as to how the frame format and field encoding works; if a specific JS construct does the job that would be fine as implementation vehicle.

[somdoron]

I'm not JS expert either.

regarding you suggestion with protocol name, I agree, it is the simplest.

I will update the ZWS document today.

[mhaberler]

excellent. So I understand we have agreement on having the protocol per se specified in binary, and let the selected protocol name choose the method for wrapping each frame if needed.

On the tag encoding: I'll make that a separate issue since different theme.

[mhaberler]

taking cues from MQTT: http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.javascript.git/tree/src/mqttws31.js - this uses arraybuffer and assumes the link is clean