If a user blocks this routine it would stop inbound message handling in
SCTP. To reduce the sharp edge fire it in a goroutine so users don't
need to worry about blocking.
`data-channels-flow-control` exhibited no differences in throughput from
this change.
Resolves#846
Fixes an issue where calling dataChannel.Close on
'connecting' state channels didn't work as expected.
When handling the `OnOpen` event detect if the
user has requested close.
Fixes#2659
It wasn't clear (at least to me)
what "idiomatic API" it's referring to.
But, judging from the `data-channels-detach` example comments,
this is what it's made for.
f29ef99b22/examples/data-channels-detach/main.go (L4)
This allows users of detached datachannels to garbage collect
resources associated with the datachannel and the sctp stream.
There is no functional change here.
Two separate potential deadlocks
1. typically the locking order is SRTP first, then DataChannel.
However, when data channel is opened, it's locking srtp when
generating an ID.
It also would return without unlocking when an error is encountered
2. recursive RLock could be potentially problematic. MediaEngine
contained a section doing so.
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
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.
The change in #1520 unnecessarily waits for a client-provided callback
to complete before release resources that are no longer necessary.
Won't have any impact in microbenchmarks that have no-op callbacks.
Release as early as possible.
OnOpen handler is sometimes called with a huge delay in
TestDataChannel_Open and causes handler_should_be_called_once
failure.
This commit minimizes mutex lock scope around handler registration
and removes redundant mutex.
Also, add sleep before closing PeerConnections in
TestDataChannel_Open to ensure all messages are processed.
DataChannel readyState should be set to Closed on PeerConnection
shutdown. If not properly set it would attempt to interact with
state that doesn't exist after the PeerConnection has been Closed.
Setting the readyState is also clearly defined in the W3C webrtc-pc
Resolves#915
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
