0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
WWebRTC LUCI CQdcsctp: Reset synchronously with incoming request
b847a434创建于 2023年10月9日历史提交
文件最后提交记录最后更新时间
BUILD.gn
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 年前
data_tracker.cc
dcsctp: Only process meaningful FORWARD-TSN Similar to change I602a8552a9a4c853684fcf105309ec3d8073f2c2, which ensured that only new DATA chunks would be processed by the reassembly queue by utilizing the data tracker, the same is done for FORWARD-TSN chunks. By having the data tracker gate keeping what is provided to the reassembly queue, the reassembly queue can be simplified as well, which is an added bonus, by removing last_assembled_tsn_watermark_ and reassembled_messages_ as those were protecting the queue from re-delivering messages it had already delivered, but as now the data tracker would ensure that it wouldn't re-process DATA/FORWARD-TSNs, that would have the same effect. In this CL, we will still update those variables and save to the handover state, but not actually read from them, and then when this change has been rolled out on the servers, I can remove the variables as well. The core change is to move validation from ReassemblyQueue::Handle to DataTracker::HandleForwardTsn. Some tests have been moved/replicated into data_tracker_test.cc to ensure that it catches the issues that the reassembly queue did earlier. Bug: webrtc:14600 Change-Id: I75c1d5911185d594f73c8b1e6bcf776e88f5b7c7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321603 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40856} 2 年前
data_tracker.h
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 年前
data_tracker_test.cc
dcsctp: Only process meaningful FORWARD-TSN Similar to change I602a8552a9a4c853684fcf105309ec3d8073f2c2, which ensured that only new DATA chunks would be processed by the reassembly queue by utilizing the data tracker, the same is done for FORWARD-TSN chunks. By having the data tracker gate keeping what is provided to the reassembly queue, the reassembly queue can be simplified as well, which is an added bonus, by removing last_assembled_tsn_watermark_ and reassembled_messages_ as those were protecting the queue from re-delivering messages it had already delivered, but as now the data tracker would ensure that it wouldn't re-process DATA/FORWARD-TSNs, that would have the same effect. In this CL, we will still update those variables and save to the handover state, but not actually read from them, and then when this change has been rolled out on the servers, I can remove the variables as well. The core change is to move validation from ReassemblyQueue::Handle to DataTracker::HandleForwardTsn. Some tests have been moved/replicated into data_tracker_test.cc to ensure that it catches the issues that the reassembly queue did earlier. Bug: webrtc:14600 Change-Id: I75c1d5911185d594f73c8b1e6bcf776e88f5b7c7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321603 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40856} 2 年前
interleaved_reassembly_streams.cc
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 年前
interleaved_reassembly_streams.h
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 年前
interleaved_reassembly_streams_test.cc
dcsctp: Add interleaved reassembly streams This is the receive-side part of supporting what is frequently called "ndata", but actually RFC8260 - "User Message Interleaving". This CL adds a new ReassemblyStreams implementation that can assemble I-DATA chunks and process I-FORWARD-TSN for partial reliability. Bug: webrtc:5696 Change-Id: I3cfbea62e7b6c02fbd3f51b43ba3fb7863cf0f88 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218506 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37128} 3 年前
reassembly_queue.cc
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 年前
reassembly_queue.h
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 年前
reassembly_queue_test.cc
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 年前
reassembly_streams.cc
dcsctp: Add interleaved reassembly streams This is the receive-side part of supporting what is frequently called "ndata", but actually RFC8260 - "User Message Interleaving". This CL adds a new ReassemblyStreams implementation that can assemble I-DATA chunks and process I-FORWARD-TSN for partial reliability. Bug: webrtc:5696 Change-Id: I3cfbea62e7b6c02fbd3f51b43ba3fb7863cf0f88 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218506 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37128} 3 年前
reassembly_streams.h
dcsctp: Restore from handover as separate methods Before this CL, some components, e.g. the SendQueue, was first created and then later restored from handover state, while some were created from the handover state, as an optional parameter to their constructors. This CL will make it consistent, by always creating the components in a pristine state, and then modifying it when restoring them from handover state. The name "RestoreFromState" was used to be consistent with SendQueue and the socket. This is just refactoring. Bug: None Change-Id: Ifad2d2e84a74a12a93abbfb0fe1027ebb9580e73 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267006 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37384} 3 年前
traditional_reassembly_streams.cc
dcsctp: Restore from handover as separate methods Before this CL, some components, e.g. the SendQueue, was first created and then later restored from handover state, while some were created from the handover state, as an optional parameter to their constructors. This CL will make it consistent, by always creating the components in a pristine state, and then modifying it when restoring them from handover state. The name "RestoreFromState" was used to be consistent with SendQueue and the socket. This is just refactoring. Bug: None Change-Id: Ifad2d2e84a74a12a93abbfb0fe1027ebb9580e73 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267006 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37384} 3 年前
traditional_reassembly_streams.h
dcsctp: Make use of log_prefix consistent The log_prefix frequently used in dcSCTP is intended to be used to separate logs from different sockets within the same log output, typically in unit tests. Every log entry always has the file and line, so it's not important to add more information to the log prefix that indicates _where_ it's logged. So those have been removed. Also, since log_prefix is a string (typically 32 bytes) and it's never changing during the lifetime of the socket, pass and store it as a absl::string_view to save memory. Bug: None Change-Id: I10466710ca6c2badfcd3adc5630426a90ca74204 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274704 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39571} 3 年前
traditional_reassembly_streams_test.cc
dcsctp: Restore from handover as separate methods Before this CL, some components, e.g. the SendQueue, was first created and then later restored from handover state, while some were created from the handover state, as an optional parameter to their constructors. This CL will make it consistent, by always creating the components in a pristine state, and then modifying it when restoring them from handover state. The name "RestoreFromState" was used to be consistent with SendQueue and the socket. This is just refactoring. Bug: None Change-Id: Ifad2d2e84a74a12a93abbfb0fe1027ebb9580e73 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267006 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37384} 3 年前