master

WWebRTC LUCI CQdcsctp: Use InfiniteDuration for no max duration

f3e9db9e创建于 2023年10月30日历史提交

文件	最后提交记录	最后更新时间
common	dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881}	2 年前
fuzzers	dcsctp: Generate lifecycle events This adds the final piece, which makes the socket and the retransmission queue generate the callbacks. Bug: webrtc:5696 Change-Id: I1e28c98e9660bd018e817a3ba0fa6b03940fcd33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264125 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37455}	3 年前
packet	dcsctp: Rename message_id to mid MID is a RFC8260 property on an I-DATA chunk, replacing the SSN property on the DATA chunk in non-interleaved message. The MID stands for "Message Identifier", and it was frequently named "message_id" in the source code, but sometimes "mid". To be consistent and using the same terminology as is most common in the RFC, use "mid" everywhere. This was triggered by the need to introduce yet another "message identifier" - but for now, this is just a refacotring CL. Bug: None Change-Id: I9cca898d9f3a2f162d6f2e4508ec1b4bc8d7308f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322500 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40876}	2 年前
public	dcsctp: Exit deferred stream reset on FORWARD-TSN https://datatracker.ietf.org/doc/html/rfc6525#section-5.2.2: E2: If the Sender's Last Assigned TSN is greater than the cumulative acknowledgment point, then the endpoint MUST enter "deferred reset processing". ... until the cumulative acknowledgment point reaches the Sender's Last Assigned TSN. The cumulative acknowledgement point can not only be reached by receiving DATA chunks, but also by receiving a FORWARD-TSN that instructs the receiver to skip them. This was only done for DATA and not for FORWARD-TSN, which is now corrected. Additionally, an unnecessary implicit sending of SACK after having received FORWARD-TSN was removed as this is done anyway every time a packet has been received. This unifies the processing of DATA and FORWARD-TSN more. Bug: webrtc:14600 Change-Id: If797d3c46e741074fe05e322d0aebec765a87968 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321400 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40811}	2 年前
rx	dcsctp: Reset synchronously with incoming request When a sender has requested a stream to be reset, and the last sender assigned TSN hasn't been received yet, the receiver will enter deferred reset mode, where it will store any data chunks received after that given TSN, and replay those later, when the stream has been reset. Before this CL, leaving deferred mode was done as soon as the sender's last assigned TSN was received. That's actually not how the RFC describes the process[1], but was done that way to properly handle some sequences of RE-CONFIG and FORWARD-TSN. But after having read the RFCs again, and realizing that whenever RFC6525 mention "any data arriving", this also applies to any FORWARD-TSN[2] - it's better to reset streams synchronously with the incoming requests, and defer not just DATA past the sender last assigned TSN, but also any FORWARD-TSN after that TSN. This mostly simplifies the code and is mostly a refactoring, but most importantly aligns it with how the resetting procedure is explained in the RFC. It also fixes two bugs: * It defers FORWARD-TSN *as well as* DATA chunks with a TSN later than the sender's last assigned TSN - see test case. The old implementation tried to handle that by exiting the deferred reset processing as soon as it reached the sender's last assigned TSN, but it didn't manage to do that in all cases. * It only defers DATA chunks for streams that are to be reset, not all DATA chunks with a TSN > sender's last assigned TSN. This was missed in the old implementation, but as it's now implemented strictly according to the RFC, this was now done. [1] https://datatracker.ietf.org/doc/html/rfc6525#section-5.2.2 [2] RFC6525 cover stream resetting, and RFC3758 cover FORWARD-TSN, and the combination of these is not covered in the RFCs. Bug: webrtc:14600 Change-Id: Ief878b755291b9c923aa6fb4317b0f5c00231df4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322623 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40889}	2 年前
socket	dcsctp: Use InfiniteDuration for no max duration Before this change, a timer could have an optional max duration. Either that value was present, and that limited the max duration of the timer, or it was absl::nullopt, which represented "no limit". To simplify the interface, this CL makes that value "not optional" by having it always present. The previous "no limit" is now represented by DurationMs::InfiniteDuration. This is just a refactoring of internal interfaces - public interfaces are left untouched. Bug: webrtc:15593 Change-Id: I80df1d9b2f4d208411ce6cb5045db0a57865e3b4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325280 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#41040}	2 年前
testing	dcsctp: Rename message_id to mid MID is a RFC8260 property on an I-DATA chunk, replacing the SSN property on the DATA chunk in non-interleaved message. The MID stands for "Message Identifier", and it was frequently named "message_id" in the source code, but sometimes "mid". To be consistent and using the same terminology as is most common in the RFC, use "mid" everywhere. This was triggered by the need to introduce yet another "message identifier" - but for now, this is just a refacotring CL. Bug: None Change-Id: I9cca898d9f3a2f162d6f2e4508ec1b4bc8d7308f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322500 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40876}	2 年前
timer	dcsctp: Use InfiniteDuration for no max duration Before this change, a timer could have an optional max duration. Either that value was present, and that limited the max duration of the timer, or it was absl::nullopt, which represented "no limit". To simplify the interface, this CL makes that value "not optional" by having it always present. The previous "no limit" is now represented by DurationMs::InfiniteDuration. This is just a refactoring of internal interfaces - public interfaces are left untouched. Bug: webrtc:15593 Change-Id: I80df1d9b2f4d208411ce6cb5045db0a57865e3b4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325280 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#41040}	2 年前
tx	dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881}	2 年前
BUILD.gn	dcsctp: Add socket fuzzer helper The socket fuzzer is build as a structure-aware fuzzer where the full public API is exercised as well as receival of SCTP packets with random sequences of valid chunks. It begins by putting the socket in a defined starting state and then, based on the fuzzing data, performs a sequence of operations on the socket such as receiving packets, sending data, resetting streams or expiring timers. This is the first iteration, and when running it a while and analyzing code coverage, it will be modified to perform better. It could probably be a little more random. Bug: webrtc:12614 Change-Id: I50d6ffaecef5722be5cf666fee2f0de7d15cc2e8 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218500 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33998}	4 年前
OWNERS	dcsctp: Add OWNERS file Bug: webrtc:12614 Change-Id: I4a2523f4923ebac59f01e3c7d0e7e9767294c1a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215683 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33783}	5 年前