5

I use ordered set to true, however when many (1000 or more) messages are sent in a short period of time (< 1 second) the messages received are not all received in the same order.

rtcPeerConnection.createDataChannel("app", {
   ordered: true,
   maxPacketLifeTime: 3000
});

I could provide a minimal example to reproduce this strange behavior if necessary.

I also use bufferedAmountLowThreshold and the associated event to delay when the send buffered amount is too big. I chose 2000 but I don't know what the optimal number is. The reason I have so many messages in a short period of time is because I don't want to overflow the maximum amount of data sent at once. So I split the data into 800 Bytes packs and send those. Again I don't know what the maximum size 1 message can be. 

const SEND_BUFFERED_AMOUNT_LOW_THRESHOLD = 2000; //Bytes
rtcSendDataChannel.bufferedAmountLowThreshold = SEND_BUFFERED_AMOUNT_LOW_THRESHOLD;
const MAX_MESSAGE_SIZE = 800;

Everything works fine for small data that is not split into too many messages. The error occurs randomly for big files only.

Walle Cyril
  • 3,087
  • 4
  • 23
  • 55
  • What browser is this? – jib Oct 28 '16 at 05:36
  • it happens between firefox and chrome, both ways – Walle Cyril Oct 28 '16 at 12:36
  • I don't think WebRTC guarantees message order. Have you seen documentation saying it does? – ssube Oct 28 '16 at 14:15
  • https://www.w3.org/TR/webrtc/#idl-def-rtcdatachannelinit , "If set to false, data is allowed to be delivered out of order. The default value of true, guarantees that data will be delivered in order." – Walle Cyril Oct 28 '16 at 14:21
  • A repro case would be useful. I'd suggest filing a bug with the WebRTC bug tracker: https://webrtc.org/bugs/ – Chuck Hays Oct 28 '16 at 16:44
  • I will release a minimal example to produce the bug in a few. – Walle Cyril Oct 28 '16 at 17:53
  • I suppose you will have to put a sequence number in each message, and then use that sequence number when reassembling them. Given they are fixed length chunks it shouldn't be too much work to do, just slap them into a buffer as you go, and when you have received all the expected messages you are done. It does add some overhead to the message data and processing, but you probably don't have much of a choice – Mikkel Oct 28 '16 at 21:34
  • I filled a bug here https://bugs.chromium.org/p/webrtc/issues/detail?id=6628 direct zip file repro case: https://bugs.chromium.org/p/webrtc/issues/attachment?aid=257059 – Walle Cyril Oct 30 '16 at 00:57

1 Answers1

4

In 2016/11/01 , there is a bug that lets the dataChannel.bufferedAmount value change during the event loop task execution. Relying on this value can thus cause unexpected results. It is possible to manually cache dataChannel.bufferedAmount, and to use that to prevent this issue.

See https://bugs.chromium.org/p/webrtc/issues/detail?id=6628

Walle Cyril
  • 3,087
  • 4
  • 23
  • 55