0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
WWebRTC LUCI CQdcsctp: Use InfiniteDuration for no max duration
f3e9db9e创建于 2023年10月30日历史提交
文件最后提交记录最后更新时间
BUILD.gn
dcsctp: Add retransmission counters to metrics Bug: webrtc:15458 Change-Id: Ib90cb0b9a94e1f358685ed319538654b0c8ed5c4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318581 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40683} 2 年前
DEPS
dcsctp: Add network/throughput tests This initial version contains a few tests, testing both lossy, non-lossy and bandwidth limited networks. It uses simulated time, and runs much faster than wall time on release builds, but slower on debug when there is a lot of outstanding data (high throughput) as there are consistency checks on outstanding data. Because of that, some tests had to be disabled in debug build. Bug: webrtc:12943 Change-Id: I9323f2dc99bca4e40558d05a283e99ce7dded7f1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225201 Reviewed-by: Artem Titov <titovartem@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35124} 4 年前
callback_deferrer.cc
dcsctp: Add API for lifecycle events This CL adds the API to enable message lifecycle events to be generated. Those can in turn be used to generate metrics, e.g. latency metrics tracking the time to send a message, the time until it's acknowledged, and metrics tracking how often messages are expired. This will be used to validate that message interleaving really improves latency for high priority data channels. The actual implementation of the API will be provided in follow-up CLs. Bug: webrtc:5696 Change-Id: Ic06f8244d1c79a336975e35479130521dff17519 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264141 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37396} 3 年前
callback_deferrer.h
dcsctp: Add API for lifecycle events This CL adds the API to enable message lifecycle events to be generated. Those can in turn be used to generate metrics, e.g. latency metrics tracking the time to send a message, the time until it's acknowledged, and metrics tracking how often messages are expired. This will be used to validate that message interleaving really improves latency for high priority data channels. The actual implementation of the API will be provided in follow-up CLs. Bug: webrtc:5696 Change-Id: Ic06f8244d1c79a336975e35479130521dff17519 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264141 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37396} 3 年前
capabilities.h
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
context.h
dcsctp: Add Context In the Socket module, there are a few (two, to be exact right now, but the goal is to have even more) separate "handlers" that are responsible for a feature set. These handlers must have an API to interact with the rest of the socket - and this is the API. Mocks are also added. Bug: webrtc:12614 Change-Id: If19b43bf99a784bba3a42467d0ed3abdd8b4c62c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214128 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33826} 5 年前
dcsctp_socket.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 年前
dcsctp_socket.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 年前
dcsctp_socket_network_test.cc
Remove usage of rtc::MessageHandler in net/dcsctp Bug: webrtc:9702 Change-Id: I80f7fb7406f91a9bfc80e040a72d4af4950187fb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272062 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Victor Boivie <boivie@webrtc.org> Auto-Submit: Danil Chapovalov <danilchap@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37818} 3 年前
dcsctp_socket_test.cc
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 年前
heartbeat_handler.cc
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 年前
heartbeat_handler.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 年前
heartbeat_handler_test.cc
Reland "dcsctp: Support zero checksum packets" This reverts commit 45eae346930aedbf4624d054e0633c94b397b8ec. It was found not to be the root cause of the performance regression, so it's safe to reland. Bug: webrtc:14997 Change-Id: I67c90752875bf4071cbdd5adfa462a37f4d4ceab Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302162 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#39910} 3 年前
mock_context.h
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767} 4 年前
mock_dcsctp_socket_callbacks.h
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 年前
packet_sender.cc
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
packet_sender.h
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
packet_sender_test.cc
dcsctp: Add PacketSender This is mainly a refactoring commit, to break out packet sending to a dedicated component. Bug: webrtc:12943 Change-Id: I78f18933776518caf49737d3952bda97f19ef335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228565 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34772} 4 年前
state_cookie.cc
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
state_cookie.h
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
state_cookie_test.cc
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
stream_reset_handler.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 年前
stream_reset_handler.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 年前
stream_reset_handler_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 年前
transmission_control_block.cc
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 年前
transmission_control_block.h
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前
transmission_control_block_test.cc
Reapply "dcsctp: Negotiate zero checksum" The handover state has been added with commit daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7. This reverts commit 014cbed9d2377ec0a0b15f2c48b21a562f770366. Bug: webrtc:14997 Change-Id: Ie84f3184f3ea67aaa6438481634046ba18b497a6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320941 Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40794} 2 年前