Lennart Grahl c2ebc3e45e Bug 979417 - Implement EOR when receiving and explicit EOR when sending on data channels (including DCEP). r=drno,jesup ... This allows sending and receiving arbitrarily (we limit to 1 GiB atm) sized messages while not relying on the deprecated PPID fragmentation/reassembly mode. The code already supports the ndata extension but it's not activated, yet. Without the SCTP ndata extension, a large data channel message will monopolise the SCTP association. While this is a problem, it is a temporary solution until the extension is being activated. Keep in mind that every application that uses data channels currently does fragmentation/reassembly on application-level and it's unlikely that this will change until the popular implementations (libwebrtc) implement EOR as well. Moreover, until the WebRTC API specifies an API that hands over partial messages, doing application-level fragmentation/reassembly is still useful for very large messages (sadly). We fall back to PPID-based fragmentation/reassembly mode IFF a=max-message-size is not set in the SDP and the negotiated amount of SCTP inbound streams is exactly 256. Other implementations should avoid using this combination (to be precise, other implementations should send a=max-message-size). It also changes behaviour of RTCDataChannel.send which now raises TypeError in case the message is too large for the other peer to receive. This is a necessity to ensure that implementations that do not look at the EOR flag when receiving are always able to receive our messages. Even if these implementations do not set a=max-message-size, we use a safe default value (64 KiB, dictated by the spec) that every implementation should be able to receive, with or without EOR support. * Due to the use of explicit EOR, this required some major refactoring of all send-related and deferred sending functions (which is now a lot less complex). There's now only one place where `usrsctp_sendv` is being used. * All data channel messages and DCEP messages will be sent without copying them first. Only in case this fails (e.g. usrsctp's buffer is full), the message will be copied and added to a buffer queue. * Queued data channel messages will now be re-sent fairly (round-robin). * Maximum message size and the PPID-based fragmentation are configurable using about:config (media.peerconnection.sctp.force_ppid_fragmentation and media.peerconnection.sctp.force_maximum_message_size). * Enable interleaving of incoming messages for different streams (preparation for SCTP ndata, has no effect until it is enabled). * Enable interleaving of outgoing messages (disabled if SCTP ndata has not been negotiated). * Add pending messages flag to reduce performance impact from frequent calls to SendDeferredMessages. * Handle partial delivery events (for cases where a partially delivered message is being aborted). * Close a data channel/the connection in case the message is too large to be handled (this is only applied in cases where the remote peer ignores our announced local maximum message size). * Various size_t to uint32_t conversions (message length) and back should be safe now. * Remove aUsingDtls/mUsingDtls from DataChannelConnection. * Set maximum message size in SDP and in the data channel stack. * Replace implicit NS_ENSURE_*'s with explicit NS_WARN_IF's. * Add SetMaxMessageSize method for late-applying those signalling parameters when a data channel has been created before the remote SDP was available. * Limit remote maximum message size and add a GetMaxMessageSize method for a future implementation of RTCSctpTransport.maxMessageSize. MozReview-Commit-ID: FlmZrpC5zVI --HG-- extra : rebase_source : 54e1b838c788a3abbded4fb32fe7c2788f8a9bc0		2017-07-26 13:18:54 +02:00
..
datachannel	Bug 979417 - Implement EOR when receiving and explicit EOR when sending on data channels (including DCEP). r=drno,jesup	2017-07-26 13:18:54 +02:00
src
sctp_update.log
update_sctp.sh