It simplifies tracking amount of unsent data for all data channels,
including ones in closing state. Especially useful for IoT apps
which use multiple data channels and have to monitor memory usage.
https://github.com/pion/webrtc/pull/2696 introduced removing
datachannels from the sctptransport for better garbage collection.
That PR introduced a race condition for data channels created before
connection establishment. When an out of band negotiated data channel,
created before peerconnection establishment is detached, there's a race
between the data channel being removed from `r.dataChannels` and it
being copied in to the existing data channel slice in the
acceptDataChannels goroutine.
This PR fixes this race by copying the slice before any datachannels
could be detached.
This allows users of detached datachannels to garbage collect
resources associated with the datachannel and the sctp stream.
There is no functional change here.
A race existed with Negotiated DataChannels before this. Before
the remote could sends us a DataChannel message before the
datachannel was negotiated locally. We would then discard the
message and print an error.
This PR moves the processing of remote datachannel messages after
we have registered all local ones. It also informs
datachannel.Accept of existing datachannels in order to prevent
any initialization logic from proceeding incorrectly.
Fix regression from 0180ee. Before Datachannels would always fire
OnOpen. Now they only fire when DCEP ACK is received. This caused
OnOpen to not be fired for negotiated channels. This re-enables
the previous behavior of firing OnOpen for negotiated channels.
Using an improvment of pion/datachannel, the channel opener can now
set an event to be called when the DATA_CHANNEL_ACK message is recieved
Resolves#1063
Relates to pion/datachannel#81
(*SCTPTransport).generateAndSetDataChannelID performed a double loop to
find the next available data channel ID. This changes that behavior to
generate a lookup map with the taken IDs first, so generating a data
channel ID takes much less time.
Before, it would take more than 1000ms to generate the next data channel
ID once you had roughly 50k of them. Now it only takes 4ms at that same
point.
Fixes#1945
DataChannel.open would panic during which if PeerConnection is closed,
stopping underlying sctpTransport which sets association to nil;
And ensureSCTP() method doesn't guarantee sctpTransport's availability
out of it's own scope.
PeerConnection.Close() doesn't match the W3C RFC on closing,
re-order the transports so that they close in the proper order.
In the future we will use the DTLS Close alert and RTCP Bye to
better communicate shutdown
Before we computed DataChannel IDs before signaling, this
is incorrect because IDs must take into account if we are
running an DTLS Client or Server.
This updates the DataChannel ID generation code to take this
into account before generating a streamId.
Resolves#908
Pass association to readLoop instead of accessing SCTPTransport
inside readloop. It is possible that before the read loop starts
the SCTPTransport assocation could be cleared, this would cause
us to pass a nil assocation to pion/datachannel
Resolves#571
