8

I'm experimenting with webRTC and it seems that there's an arbitrary limit to how many bytes can be sent in each message. This guy whose example I used chose a limit of 100 (plus some) bytes. In my tests it seems to be close to 200 bytes. However from reading on TCP and UDP those protocols support packages of up to around 65kb and even when taking the MTU for different types of networks into account it should still be a lot more space available than ~200 bytes.

The only source I've found that mentions a hard limit is this WebRTC Data Channel Protocol draft but it only says TBD.

So my questions are:

  1. if there's any source that specifies the current message size limit in any browser?
  2. if I can assume that the limit is always the same, and if not if there's any way my app can be made aware of the limit?
Community
  • 1
  • 1
Andreas Hultgren
  • 14,763
  • 4
  • 44
  • 48
  • In case someone else find this with similar problems I've found some almost related info. Currently chrome limits traffic to about 3kbps in lieu of congestion detection. This limit is said be removed when they've figured out how to detect that. I'm not sure though if the problem I experienced is caused by that. – Andreas Hultgren Mar 22 '13 at 15:03
  • Im dealing with the same problem. Is there a limit in firefox instead? – charlypu Mar 23 '13 at 12:11
  • Firefox doesn't seem to have this limit and even supports sending Blobs. But with firefox I can't establish a connection between tabs/browsers instead... – Andreas Hultgren Mar 23 '13 at 13:27
  • Any 2016 updates worth knowing about ? – Walle Cyril Oct 22 '16 at 11:44

2 Answers2

5

The sharefest project found a way around the rate throttling - you can modify the outgoing offer to change the bandwidth setting (per http://www.ietf.org/rfc/rfc2327.txt)

Details here: https://github.com/Peer5/ShareFest/blob/master/public/js/peerConnectionImplChrome.js#L201

From my own experience you're still limited to ~800 bytes per message.

hcliff
  • 433
  • 5
  • 16
  • Thanks! I'll try it out as soon as I get a chance. – Andreas Hultgren Apr 23 '13 at 12:13
  • Seems to work! Large files crashed the tab, but I assume that's caused by my specific implementation. – Andreas Hultgren Apr 26 '13 at 09:15
  • Are you trying to load the whole file at once? Use slicing instead to read the file bit by bit: http://www.html5rocks.com/en/tutorials/file/dndfiles/ for an overview of slicing, and my own project http://hcliff.github.com/ampere for more relating to dealing with large files and webrtc :) – hcliff Apr 26 '13 at 13:37
  • Yes I'm slicing the file, but the "large" file is only 100kB so that can't be where the problem is (I suspect my torrent-ish approach is similar to yours, but in a more experimental state). I'm sure I'll figure it out though when (if) I get time to dig down into it again. – Andreas Hultgren Apr 26 '13 at 14:17
  • 1
    For posterity: https://github.com/Peer5/ShareFest/blob/8fcb0c06fc6ab06a1d0ee6b3d734e5832973d972/public/js/peerConnectionImplChrome.js#L202 – Charles Aug 21 '13 at 22:01
2

I've been testing sending jpegs to chrome 57 over the data channel, and messages up to 64k seem to be reliable now.

The webRTC data channel does have a reliability mechanism, it uses SCTP over DTLS (over UDP) - SCTP lets you set reliability and ordering behaviour, but by default WebRTC uses ordered+reliable - meaning you get similar semantics to that of TCP - except that the message boundaries are preserved - at least in theory.

In practice Chrome may deliver partial messages up to the javascript if it runs out of space so it is best to check that you have a complete message before processing it.

Tim Panton
  • 469
  • 3
  • 4