Binarypack mandatory?

[ivelin]

Wondering if binary pack/unpack is mandatory with the latest browser implementations of WebRTC serialization?

As I am working on the Python client port I noticed that the binary pack dependency would also have to be ported. In the meanwhile it seems like more recent peer libraries like simple-peer rely on the default serialization standard which simplifies cross language portability.

Does it make sense to make binary packing optional?

[afrokick]

It needs for object serialization. You can simply call dataConnection.send({"score":1}) without any manual converting to blob/arraybuffer.

You can implement only JSON type for serialization for Python port.

[ivelin]

@afrokick thank you for the suggestions.

Let me make sure I understand:

1. If I use send(score:1) peerjs will use the default WebRTC serialization which can be decoded without bunarypack port on the Python side?

2. Does the opposite hold? Can I send binary data from the python side with a parameter that hints to peerjs to skip binarypack?

3. For JSON serialization. Would that work for json encoding of large binary files such as images or recorded videos? Other than the base64 overhead of json binary encoding , would there be an issue with chunking it into smaller datachannel packets?

Thank you!

[ivelin]

Looking at the dataconnection code, it appears that either its binary mode and pack/unpack is used or its json mode which expects the whole chunk to be a valid json object. I don't see a scenario that allows large messages using a default webrtc serialization mode:

    if (isBinarySerialization) {
      if (datatype === Blob) {
        // Datatype should never be blob
        util.blobToArrayBuffer(data as Blob, (ab) => {
          const unpackedData = util.unpack(ab);
          this.emit(ConnectionEventType.Data, unpackedData);
        });
        return;
      } else if (datatype === ArrayBuffer) {
        deserializedData = util.unpack(data as ArrayBuffer);
      } else if (datatype === String) {
        // String fallback for binary data for browsers that don't support binary yet
        const ab = util.binaryStringToArrayBuffer(data as string);
        deserializedData = util.unpack(ab);
      }
    } else if (this.serialization === SerializationType.JSON) {
      deserializedData = this.parse(data as string);
    }

[afrokick]

@ivelin 1,2) If you want to send/receive "raw" data, you can set dataConnection.serialization = "raw";(instead of 'raw' you can use any string except json, binary, binary-utf8) 3) AFAIK we didn't support chunking for JSON. So you need to use binary serialization to slice it to chunks.

You can use your own implementation of parse/stringify for json serialization https://github.com/peers/peerjs/pull/592

[ivelin]

1,2) If you want to send/receive "raw" data, you can set dataConnection.serialization = "raw";(instead of 'raw' you can use any string except json, binary, binary-utf8)

Thank you, @afrokick . I get it now. You are saying that any unknown binary serialization type will skip the unpack logic in _handleDataMessage() when DataConnection receives messages and respectively the pack logic in send() when messages are sent out.

[ivelin]

OK, I am able to exchange raw data messages with peerjs python. Next stop is handling bigger chunks of data. Since PeerJS only chunks in binary format using binarypack, I would have to port all of peerjs binarypack as well.

Question: Is it feasible to switch binarypack with the popular MessagePack library which has support in 50 programming languages?

I tried unpacking binary pack messages on the python end with the msgpack library referenced on the msgpack.org site, but it looks like peerjs binarypack is not sending data in a msgpack compatible format:

msgpack.exceptions.ExtraData: unpack(b) received extra data.

Since peerjs binary pack claims to be 95% msgpack, I wonder if we can make the switch to simplify support for PeerJS in more programming languages.

[jonasgloning]

Hey @ivelin, I know it took too long, but I just published support for MessagePack and CBOR.