wngr / async-datachannel Goto Github PK

Hello, your github source code seems to be on version 0.2.2 while crates.io has version 0.3, did you forget to push on github?
crates.io link: https://crates.io/crates/async-datachannel

I noticed that sometimes when I send large amounts of data (e.g. hundreds of megabytes), sometimes messages get lost. Usually it's from the end, but it can be elsewhere.

I have modified the smoke test to reproduce the issue. It is most easy to reproduce it in release mode. The issue appears in one of two ways:

EXPECTED 202, RECEIVED 219 at 78758400

in the stderr of the recipient (the one that has fewer arguments).

Another way is to wait until the end and see that the recipient has not received all the data, while the sender is waiting for acknowledgement from the peer.

I suggest redirecting output to files when running the test. It doesn't also seem very deterministic, so fidgeting with buffer sizes might also impact this..

I don't yet know if the issue is in this library or libdatachannel, but I'll report it here first as I have not written a test case for libdatachannel yet.

edit: updated direct url to smoke.rs

It seems the interface is designed so that it is impossible to create multiple DataStreams for one PeerConnection. Line 240 of lib.rs says:

    pub async fn dial(self, label: &str) -> anyhow::Result<DataStream> {

taking self in, disallowing it to be called multiple times. In datachannel-rs there is no such limitation, as can be seen from line 355 of peerconnection.rs:

    pub fn create_data_channel_ex<C>(
        &mut self,
        label: &str,
        dc_handler: C,
        dc_init: &DataChannelInit,
    ) -> Result<Box<RtcDataChannel<C>>>

The documentation for libdatachannel doesn't outright say that there can be multiple DataChannels, but it does say that rtcCreateDataChannel adds a datachannel to a Peer Connection and in general this is possible.

It can be useful to have e.g. one unordered and unreliable DataChannel paired with an ordered an reliable DataChannel.

It seems some internal changes are needed to make this happen, peer_con: Arc<Mutex<Box<RtcPeerConnection<ConnInternal>>>> in PeerConnection probably needs to be an Arc as well, for one. I guess I misread it :).