You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can achieve ~110% of the original speed by disabling checksum verification at the receiver side.
Create issues for TODO items
Move and close related issues from RAWRTC
Proper documentation
If a function can fail (even if only due to invalid input parameters), it will return a enum rawrtc_code.
Function parameters ending with p will usually be de-referenced and it's value will be changed. The documentation of the parameter will clearly indicate whether or not that's the case.
Multithreading
The below mutex documentation only applies if the SCTP iterator thread is not only idling (it does look like it's just idling and can be removed - see SCTP iterator thread NEAT-project/usrsctp-neat#12).
Locking: Always hold a lock to the mutex by calling re_enter_thread (you can set your own mutex by calling re_set_mutex(your_mutex)) before calling functions of this library. Some event loops always hold a lock implicitly when handling callbacks. So, if the event loop's mutex has been applied and if used inside such a context, you do not need to lock explicitly.
Unlocking: If explicitly locked by calling re_enter_thread, you need to explicitly unlock by calling re_leave_thread.
FAQ
Is it a complete SCTP implementation? No, it uses usrsctp underneath.
Where is it intended to be used? In a WebRTC or ORTC stack on top of DTLS.
Who should use this? Everyone who is interested in having support for data channels who already has an ICE/DTLS stack.
But I also need ICE/DTLS! Check out RAWRTC.
Can I access struct members directly and do hacky stuff? Certainly, just import rawrtcdc_internal.h. Be aware, there may be breaking API changes even between minor versions when accessing non-public functions and structures. If you're missing something essential, create a new issue or make a pull request instead of using the internal API.
Warnings
Under no circumstances should you mem_deref stuff that's being used inside of a handler function called by RAWRTCDC or you will see segfaults. Instead, schedule removal and do it after the handler function returned.
Backport (from RAWRTCC to RAWRTCDC and RAWRTC)
Fix callback typedefs to make them documentable
Project author in CMake
Version parsing from rawrtc*.h
Generated rawrtc*_configuration.h header
Install public header -> Install headers
Remove generated rawrtc*_internal.h header
Docs (all files)
Ensure debug level can still be set (and defaults to 5) across libraries. Test this inside rawrtc-terminal-demo.
Consider setting states earlier and therefore get rid of issues when a callback calls a function during a state change that also checks the state. This would also get rid of the quirky helper flags.
Make SCTP send/receive window configurable
Test ARM detection.
Consider requiring to mem_ref of the channel when calling rawrtc_data_channel_handler or close the channel immediately. (No implicit reference anymore.)
Sending: Wait for buffered amount low, send, repeat (normal/streamed)
Use a send buffer per channel.
Implement setting buffered amount low threshold
Get buffered amount info from usrsctp's internal buffers & our own buffers
Raise buffered amount low (on open, after each write if buffered amount is low enough)
Receiving: Pause transport if busy, unpause transport, receive message event, repeat (normal/streamed)
Add a way to pause/unpause the data transport for incoming messages (something like rawrtc_data_transport_pause_incoming(true/false))
Warning: This will also pause all other channels. Talk to the usrsctp folks to find out whether it's possible to signal backpressure on a single stream without affecting other streams.
Remember SCTP read event if paused
When unpausing, handle pending SCTP read events
The text was updated successfully, but these errors were encountered:
To Do:
rawrtc_sctp_context
Enter event loop thread (?)Leave event loop thread (?)rawrtc_sctp_transport_feed_inbound
rawrtc_sctp_transport_set_mtu
rawrtc_sctp_transport_get_mtu
rawrtc_sctp_transport_enable_mtu_discovery
rawrtc_sctp_transport_set_context
rawrtcdc_timer_tick
struct rawrtc_data_channel_options
.rawrtc_sctp_transport_get_capabilities
intosctp_transport.c
rawrtc_sctp_transport_state_to_name
to the bottom ofsctp_transport.c
TODO
itemsenum rawrtc_code
.p
will usually be de-referenced and it's value will be changed. The documentation of the parameter will clearly indicate whether or not that's the case.re_enter_thread
(you can set your own mutex by callingre_set_mutex(your_mutex)
) before calling functions of this library. Some event loops always hold a lock implicitly when handling callbacks. So, if the event loop's mutex has been applied and if used inside such a context, you do not need to lock explicitly.re_enter_thread
, you need to explicitly unlock by callingre_leave_thread
.rawrtcdc_internal.h
. Be aware, there may be breaking API changes even between minor versions when accessing non-public functions and structures. If you're missing something essential, create a new issue or make a pull request instead of using the internal API.mem_deref
stuff that's being used inside of a handler function called by RAWRTCDC or you will see segfaults. Instead, schedule removal and do it after the handler function returned.rawrtc*.h
rawrtc*_configuration.h
headerrawrtc*_internal.h
header5
) across libraries. Test this insiderawrtc-terminal-demo
.Afterwards:
mem_ref
of the channel when callingrawrtc_data_channel_handler
or close the channel immediately. (No implicit reference anymore.)const * const
orconst* const
- decide!rawrtc_data_transport_pause_incoming(true/false)
)The text was updated successfully, but these errors were encountered: