Allow ordered:false and maxRetransmits:0 (unreliable) createDataChannel parameters

Does AIORTC support unordered/unreliable data channels with no retransmits? I’d like to create a data channel that simply drops undelivered messages.

I’ve been experimenting with data channels, trying to use various “UDP-like” configurations as described in this blog post (or, using slightly older docs, this section of High Performance Browser Networking), but I’ve been unsuccessful so far.

I created a branch off 0.9.12 and modified your server example client.js and index.html to allow setting these alternate createDataChannel() options:

{
    ordered: false,
    maxRetransmits: 0
};

Referring to my fork/branch: When using the alternate options it connects but never receives ‘pong’ responses from server.py:

*** Creating data channel with options={"ordered":false,"maxRetransmits":0}
- open
> ping
> ping
...
> ping
> ping
- close

Questions:

1. Am I doing something wrong as far as WebRTC spec, or is this something that aiortc simply doesn’t support at this time?
2. Are there any RTCDataChannel option combinations that will work to disable data channel re-transmits in aiortc?

Also: Thanks for your efforts on aiortc – I’ve been experimenting with it for a while now, and it’s been very helpful so far. I’d be glad to help with development/debugging as appropriate.

Version info:

AIORTC 0.9.12 Chrome Version 70.0.3538.102 (Official Build) (64-bit) Firefox Version 63.0 (64-bit) Python 3.6.6 Ubuntu 16.04.5 LTS w/4.15.0-39-generic kernel

[jlaine]

Let’s keep this issue open to track the lack of support for unordered / max retransmits, I’ve got some pending code.

[jlaine]

There is no “hack” for magically getting unordered / no retransmit mode, if you need it you really do need to go and implement it.

• unordered delivery : this involves tweak or re-writing the InboundStream class (and writing plenty of tests):

https://github.com/jlaine/aiortc/blob/4614d495c912bef3bf91e297a6351ce31c7b8774/aiortc/rtcsctptransport.py#L457

• limiting / disabling retransmissions is another kettle of fish, AFAICT it means implementing RFC 3758:

https://tools.ietf.org/html/rfc3758

This allows the sender to instruct the receiver to “give up” on some some missing data chunks