0

I have been trying to use WebRTC Data Channel for a game, however, I am unable to consistently send live player data without hitting the queue size limit (8KB) after 50-70 secs of playing.

Sine the data is required to be real-time, I have no use for data that comes out of order. I have initialized the data channel with the following attributes:

negotiated: true, 
id: id, 
ordered: true, 
maxRetransmits: 0, 
maxPacketLifetime: 66

The MDN Docs said that the buffer cannot be altered in any way.

Is there anyway I can consistently send data without exceeding the buffer space? I don't mind purging the buffer space as it only contains data that has been clogged up over time.

NOTE: The data is transmitting until the buffer size exceeds the 8KB space.

EDIT: I forgot to add that this issue is only occurring when the two sides are on different networks. When both are within the same LAN, there is no buffering (since higher bandwidth, I presume). I tried to add multiple Data Channels (8 in parallel). However, this only increased the time before the failure occurred again. All 8 buffers were full. I also tried creating a new channel each time the buffer was close to being full and switched to the new DC while closing the previous one that was full, but I found out the hard way (reading Note in MDN Docs) that the buffer space is not released immediately, rather tries to transmit all data in the buffer taking away precious bandwidth.

Thanks in advance.

ToddlerExpertise
  • 3
  • 3

2 Answers2

1

The maxRetransmits value is ignored if the maxPacketLifetime value is set; thus, you've configured your channel to resend packets for up to 66ms. For your application, it is probably better to use a pure unreliable channel by setting maxPacketLifetime to 0.

As Sean said, there is no way to flush the queue. What you can do is to drop packets before sending them if the channel is congested:

if(dc.bufferedAmount > 0)
     return;
dc.send(data);

Finally, you should realise that buffering may happen in the network as well as at the sender: any router can buffer packets when it is congested, and many routers have very large buffers (this is called BufferBloat). The WebRTC stack should prevent you from buffering too much data in the network, but if WebRTC's behaviour is not aggressive enough for your needs, you will need to add explicit feedback from the sender to the receiver in order to avoid having too many packets in flight.

jch
  • 5,382
  • 22
  • 41
0

I don't believe you can flush the outbound buffer, you will probably need to watch the bufferedAmount and adjust what you are sending if it grows.

Maybe handle the retransmissions yourselves and discard old data if needed? WebRTC doesn't surface the SACKs from SCTP. So I think you will need to implement something yourself.

It's an interesting problem. Would love to hear the WebRTC W3C WorkGroup takes on it if exposing more info would make things easier for you.

Sean DuBois
  • 3,972
  • 1
  • 11
  • 22