- Remove custom atomicBool implementation
- Replace all atomicBool usages with standard library sync/atomic.Bool
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
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
Data channel creation checks if the sctp transport is already
established. Because this check was incorrect, in some cases it returned
an error instead of delaying opening the data channel until the sctp
connection is established. Fixed the check. Added locking to
CreateDataChannel to avoid race condition. Added test.
This is now possible because the properties in the Go implementation
were changed to methods, which more closely matches the Wasm bindings.
Previously we needed two separate tests because of differences in the
two APIs.
The tests are run in a Node.js environment, and this does not include
any browser tests. This requires the wrtc package from npm as well as a
shim which adds portions of the WebRTC API to the global scope.
Some tests introduced here can be combined when differences between the
Go API and the WASM bindings are addressed and as missing features are
added to the WASM bindings.
We can and should add more tests in the future to improve test coverage.
This should be considered the minimum number of tests reuqired to ensure
basic functionality is working.
