How to receive data quickly?

[wojxhr]

Hi!
I have peerA and peerB connected. And peerA would asynchronously send request to peerB ask to for a data chunk(the size is from 4mb to 8mb).
When connection first established,peerA would send about 15~17 request to peerB.There is no problem in peerB,it send every data chunk successfully and quickly.But it takes long for peerA to call conn.on('data') to get the first data chunk(about 4~5s).
It's there any way to improve it?

[ProPablo]

Hey I have had similar issues for a while now without any real fix, as far as reproduction goes, I've tested using https://webrtc.github.io/samples/src/content/datachannel/filetransfer/ and it seems that datachannels transferring packets larger than the MTU is slow on android even to itself locally. The example is also using a very similiar chunking system that peerjs is using.

At first I thought I need to run it through compression but the provided example worked perfectly fine on ios and desktop. I wanted to test what would happen if I upgrade the maxMessageSize in the SDP but I was having issues using a forked version of this.

I changed the peerjs package json to have this in scripts "prepare": "npm run build" but started running into this:

And so thus far, these are my findings if anyone finds them useful. I will be trying to simply transplant peerjs into my project and make these changes instead of relying on the forking methodology for now but assistance for that would be nice :).

[jonasgloning]

Were you able to set maxMessageSize? I was under the impression this was a read-only property.

Sometimes removing .parcel-cache magically fixes all build errors.

[flyyang]

I hava simlar issue。Seems all the send done, then the data start to recevied.
Don't know why wasn't send right away.

[jonasgloning]

I suspect this had to do with the EncodingQueue. Sometimes chunks were processed in a suboptimal order, resulting in never freeing the first full object of data.

I just published PeerJS v1.5. It comes fixes this and comes with a much faster BinaryPack implementation and support for the even faster CBOR and MessagePack formats.

Please let me know if encoding makes any difference for your use-case.

[ProPablo]

Hey, hows it going, yes, the new 1.5 release with the binary pack impelementation has drastically sped up the send time especially on android. A 3.5MB picture that I used to test to send over webrtc used to take 35 seconds over local network, now takes 2 seconds! I see were just retrying every 50 milliseconds if the datachannel buffer is empty.

A few points of feedback however:

1. I would like to try the other CBOR and MessagePack way of using streams but they arent yet exposed to the api through simply peer.connect, I assume thats coming soon along with docs
2. I would still like some way of progress tracking the chunks, whenever _trySend resolves to finally datachannel.send, if we can emit an event that gives info about __peerData and the number of the chunk when it gets sent that would be great.

I know these are different issues to the one proposed and I wouldn't mind making them as seperate issues if needed.
Thank you for this

[jonasgloning]

Hey @ProPablo, that’s great to hear!

Yes, please open new issues for both. It would be sad if these were lost.

I’m currently looking towards a packed semester at university, so I wont have much time to work on PeerJS. However, I intend to gradually update the documentation throughout this period, without making significant changes to the code. Streams are then scheduled for the winter break, unless a PR is submitted earlier.