admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
webrtc_m130/net/dcsctp/rx/data_tracker_test.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

740 lines
27 KiB
C++
Raw Normal View History

dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
/*
* Copyright (c) 2021 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#include "net/dcsctp/rx/data_tracker.h"
#include <cstdint>
#include <initializer_list>
#include <memory>
#include "absl/types/optional.h"
#include "api/array_view.h"
Allow specifying delayed task precision of dcsctp::Timer. Context: The timer precision of PostDelayedTask() is about to be lowered to include up to 17 ms leeway. In order not to break use cases that require high precision timers, PostDelayedHighPrecisionTask() will continue to have the same precision that PostDelayedTask() has today. webrtc::TaskQueueBase has an enum (kLow, kHigh) to decide which precision to use when calling PostDelayedTaskWithPrecision(). See go/postdelayedtask-precision-in-webrtc for motivation and a table of delayed task use cases in WebRTC that are "high" or "low" precision. Most timers in DCSCTP are believed to only be needing low precision (see table), but the delayed_ack_timer_ of DataTracker[1] is an example of a use case that is likely to break if the timer precision is lowered (if ACK is sent too late, retransmissions may occur). So this is considered a high precision use case. This CL makes it possible to specify the precision of dcsctp::Timer. In a follow-up CL we will update delayed_ack_timer_ to kHigh precision. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/rx/data_tracker.cc;l=340 Bug: webrtc:13604 Change-Id: I8eec5ce37044096978b5dd1985fbb00bc0d8fb7e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249081 Reviewed-by: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35809}
2022-01-26 18:38:13 +01:00
#include "api/task_queue/task_queue_base.h"
dcsctp: support handover state serialization testing dcSCTP library users can set their custom g_handover_state_transformer_for_test that can serialize and deserialize the state. All dcSCTP handover tests call g_handover_state_transformer_for_test. If some part of the state is serialized incorrectly or is forgotten, high chance that it will fail the tests. Bug: webrtc:13154 Change-Id: I251a099be04dda7611e9df868d36e3a76dc7d1e1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232325 Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35035}
2021-09-20 11:35:59 +02:00
#include "net/dcsctp/common/handover_testing.h"
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
#include "net/dcsctp/packet/chunk/sack_chunk.h"
#include "net/dcsctp/timer/fake_timeout.h"
#include "net/dcsctp/timer/timer.h"
#include "rtc_base/gunit.h"
#include "test/gmock.h"
namespace dcsctp {
namespace {
using ::testing::ElementsAre;
using ::testing::IsEmpty;
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
using ::testing::SizeIs;
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
using ::testing::UnorderedElementsAre;
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
constexpr size_t kArwnd = 10000;
dcsctp: Fix post-review comments for DataTracker These are some fixes that were added after submission of https://webrtc-review.googlesource.com/c/src/+/213664 Mainly: * Don't accept TSNs that have a too large difference from expected * Renaming of member variable (to confirm to style guidelines) Bug: webrtc:12614 Change-Id: I06e11ab2acf5d307b68c3cbc135fde2c038ee690 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215070 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33721}
2021-04-13 11:23:16 +02:00
constexpr TSN kInitialTSN(11);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
class DataTrackerTest : public testing::Test {
protected:
DataTrackerTest()
: timeout_manager_([this]() { return now_; }),
Allow specifying delayed task precision of dcsctp::Timer. Context: The timer precision of PostDelayedTask() is about to be lowered to include up to 17 ms leeway. In order not to break use cases that require high precision timers, PostDelayedHighPrecisionTask() will continue to have the same precision that PostDelayedTask() has today. webrtc::TaskQueueBase has an enum (kLow, kHigh) to decide which precision to use when calling PostDelayedTaskWithPrecision(). See go/postdelayedtask-precision-in-webrtc for motivation and a table of delayed task use cases in WebRTC that are "high" or "low" precision. Most timers in DCSCTP are believed to only be needing low precision (see table), but the delayed_ack_timer_ of DataTracker[1] is an example of a use case that is likely to break if the timer precision is lowered (if ACK is sent too late, retransmissions may occur). So this is considered a high precision use case. This CL makes it possible to specify the precision of dcsctp::Timer. In a follow-up CL we will update delayed_ack_timer_ to kHigh precision. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/rx/data_tracker.cc;l=340 Bug: webrtc:13604 Change-Id: I8eec5ce37044096978b5dd1985fbb00bc0d8fb7e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249081 Reviewed-by: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35809}
2022-01-26 18:38:13 +01:00
timer_manager_([this](webrtc::TaskQueueBase::DelayPrecision precision) {
return timeout_manager_.CreateTimeout(precision);
}),
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
timer_(timer_manager_.CreateTimer(
"test/delayed_ack",
[]() { return absl::nullopt; },
TimerOptions(DurationMs(0)))),
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_(
std::make_unique<DataTracker>("log: ", timer_.get(), kInitialTSN)) {
}
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
void Observer(std::initializer_list<uint32_t> tsns,
bool expect_as_duplicate = false) {
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
for (const uint32_t tsn : tsns) {
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
if (expect_as_duplicate) {
EXPECT_FALSE(
tracker_->Observe(TSN(tsn), AnyDataChunk::ImmediateAckFlag(false)));
} else {
EXPECT_TRUE(
tracker_->Observe(TSN(tsn), AnyDataChunk::ImmediateAckFlag(false)));
}
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
}
}
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
void HandoverTracker() {
EXPECT_TRUE(tracker_->GetHandoverReadiness().IsReady());
DcSctpSocketHandoverState state;
tracker_->AddHandoverState(state);
dcsctp: support handover state serialization testing dcSCTP library users can set their custom g_handover_state_transformer_for_test that can serialize and deserialize the state. All dcSCTP handover tests call g_handover_state_transformer_for_test. If some part of the state is serialized incorrectly or is forgotten, high chance that it will fail the tests. Bug: webrtc:13154 Change-Id: I251a099be04dda7611e9df868d36e3a76dc7d1e1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232325 Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35035}
2021-09-20 11:35:59 +02:00
g_handover_state_transformer_for_test(&state);
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}
2022-06-27 20:35:37 +00:00
tracker_ =
std::make_unique<DataTracker>("log: ", timer_.get(), kInitialTSN);
tracker_->RestoreFromState(state);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
}
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
TimeMs now_ = TimeMs(0);
FakeTimeoutManager timeout_manager_;
TimerManager timer_manager_;
std::unique_ptr<Timer> timer_;
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
std::unique_ptr<DataTracker> tracker_;
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
};
TEST_F(DataTrackerTest, Empty) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, ObserverSingleInOrderPacket) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, ObserverManyInOrderMovesCumulativeTsnAck) {
Observer({11, 12, 13});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(13));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, ObserveOutOfOrderMovesCumulativeTsnAck) {
Observer({12, 13, 14, 11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, SingleGap) {
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2)));
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, ExampleFromRFC4960Section334) {
Observer({11, 12, 14, 15, 17});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(12));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 3),
SackChunk::GapAckBlock(5, 5)));
EXPECT_THAT(sack.duplicate_tsns(), IsEmpty());
}
TEST_F(DataTrackerTest, AckAlreadyReceivedChunk) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack1 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack1.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack1.gap_ack_blocks(), IsEmpty());
// Receive old chunk
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({8}, /*expect_as_duplicate=*/true);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack2 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack2.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack2.gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest, DoubleSendRetransmittedChunk) {
Observer({11, 13, 14, 15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack1 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack1.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack1.gap_ack_blocks(),
ElementsAre(SackChunk::GapAckBlock(2, 4)));
// Fill in the hole.
Observer({12, 16, 17, 18});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack2 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack2.cumulative_tsn_ack(), TSN(18));
EXPECT_THAT(sack2.gap_ack_blocks(), IsEmpty());
// Receive chunk 12 again.
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({12}, /*expect_as_duplicate=*/true);
Observer({19, 20, 21});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack3 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack3.cumulative_tsn_ack(), TSN(21));
EXPECT_THAT(sack3.gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest, ForwardTsnSimple) {
// Messages (11, 12, 13), (14, 15) - first message expires.
Observer({11, 12, 15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(13));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(13));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2)));
}
TEST_F(DataTrackerTest, ForwardTsnSkipsFromGapBlock) {
// Messages (11, 12, 13), (14, 15) - first message expires.
Observer({11, 12, 14});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(13));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest, ExampleFromRFC3758) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(102));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({102}, /*expect_as_duplicate=*/true);
Observer({104, 105, 107});
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(103));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(105));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2)));
}
TEST_F(DataTrackerTest, EmptyAllAcks) {
Observer({11, 13, 14, 15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(100));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(100));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest, SetsArwndCorrectly) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack1 = tracker_->CreateSelectiveAck(/*a_rwnd=*/100);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack1.a_rwnd(), 100u);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack2 = tracker_->CreateSelectiveAck(/*a_rwnd=*/101);
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
EXPECT_EQ(sack2.a_rwnd(), 101u);
}
TEST_F(DataTrackerTest, WillIncreaseCumAckTsn) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_EQ(tracker_->last_cumulative_acked_tsn(), TSN(10));
EXPECT_FALSE(tracker_->will_increase_cum_ack_tsn(TSN(10)));
EXPECT_TRUE(tracker_->will_increase_cum_ack_tsn(TSN(11)));
EXPECT_FALSE(tracker_->will_increase_cum_ack_tsn(TSN(12)));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
Observer({11, 12, 13, 14, 15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_EQ(tracker_->last_cumulative_acked_tsn(), TSN(15));
EXPECT_FALSE(tracker_->will_increase_cum_ack_tsn(TSN(15)));
EXPECT_TRUE(tracker_->will_increase_cum_ack_tsn(TSN(16)));
EXPECT_FALSE(tracker_->will_increase_cum_ack_tsn(TSN(17)));
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
}
TEST_F(DataTrackerTest, ForceShouldSendSackImmediately) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ForceImmediateSack();
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
}
dcsctp: Fix post-review comments for DataTracker These are some fixes that were added after submission of https://webrtc-review.googlesource.com/c/src/+/213664 Mainly: * Don't accept TSNs that have a too large difference from expected * Renaming of member variable (to confirm to style guidelines) Bug: webrtc:12614 Change-Id: I06e11ab2acf5d307b68c3cbc135fde2c038ee690 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215070 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33721}
2021-04-13 11:23:16 +02:00
TEST_F(DataTrackerTest, WillAcceptValidTSNs) {
// The initial TSN is always one more than the last, which is our base.
TSN last_tsn = TSN(*kInitialTSN - 1);
int limit = static_cast<int>(DataTracker::kMaxAcceptedOutstandingFragments);
for (int i = -limit; i <= limit; ++i) {
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_TRUE(tracker_->IsTSNValid(TSN(*last_tsn + i)));
dcsctp: Fix post-review comments for DataTracker These are some fixes that were added after submission of https://webrtc-review.googlesource.com/c/src/+/213664 Mainly: * Don't accept TSNs that have a too large difference from expected * Renaming of member variable (to confirm to style guidelines) Bug: webrtc:12614 Change-Id: I06e11ab2acf5d307b68c3cbc135fde2c038ee690 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215070 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33721}
2021-04-13 11:23:16 +02:00
}
}
TEST_F(DataTrackerTest, WillNotAcceptInvalidTSNs) {
// The initial TSN is always one more than the last, which is our base.
TSN last_tsn = TSN(*kInitialTSN - 1);
size_t limit = DataTracker::kMaxAcceptedOutstandingFragments;
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_FALSE(tracker_->IsTSNValid(TSN(*last_tsn + limit + 1)));
EXPECT_FALSE(tracker_->IsTSNValid(TSN(*last_tsn - (limit + 1))));
EXPECT_FALSE(tracker_->IsTSNValid(TSN(*last_tsn + 0x8000000)));
EXPECT_FALSE(tracker_->IsTSNValid(TSN(*last_tsn - 0x8000000)));
dcsctp: Fix post-review comments for DataTracker These are some fixes that were added after submission of https://webrtc-review.googlesource.com/c/src/+/213664 Mainly: * Don't accept TSNs that have a too large difference from expected * Renaming of member variable (to confirm to style guidelines) Bug: webrtc:12614 Change-Id: I06e11ab2acf5d307b68c3cbc135fde2c038ee690 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215070 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33721}
2021-04-13 11:23:16 +02:00
}
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
TEST_F(DataTrackerTest, ReportSingleDuplicateTsns) {
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({11, 12});
Observer({11}, /*expect_as_duplicate=*/true);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(12));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), UnorderedElementsAre(TSN(11)));
}
TEST_F(DataTrackerTest, ReportMultipleDuplicateTsns) {
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({11, 12, 13, 14});
Observer({12, 13, 12, 13}, /*expect_as_duplicate=*/true);
Observer({15, 16});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(16));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(), UnorderedElementsAre(TSN(12), TSN(13)));
}
TEST_F(DataTrackerTest, ReportDuplicateTsnsInGapAckBlocks) {
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({11, /*12,*/ 13, 14});
Observer({13, 14}, /*expect_as_duplicate=*/true);
Observer({15, 16});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 5)));
EXPECT_THAT(sack.duplicate_tsns(), UnorderedElementsAre(TSN(13), TSN(14)));
}
TEST_F(DataTrackerTest, ClearsDuplicateTsnsAfterCreatingSack) {
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({11, 12, 13, 14});
Observer({12, 13, 12, 13}, /*expect_as_duplicate=*/true);
Observer({15, 16});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack1 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
EXPECT_EQ(sack1.cumulative_tsn_ack(), TSN(16));
EXPECT_THAT(sack1.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack1.duplicate_tsns(), UnorderedElementsAre(TSN(12), TSN(13)));
Observer({17});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack2 = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Report duplicate TSNs Reporting the duplicate TSNs is a SHOULD in the RFC, and using the duplicate TNSs is a MAY, and in reality I haven't seen an implementation use it yet. However, it's good for debugging and for stats generation. Bug: webrtc:12614 Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34053}
2021-05-19 13:40:55 +02:00
EXPECT_EQ(sack2.cumulative_tsn_ack(), TSN(17));
EXPECT_THAT(sack2.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack2.duplicate_tsns(), IsEmpty());
}
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
TEST_F(DataTrackerTest, LimitsNumberOfDuplicatesReported) {
for (size_t i = 0; i < DataTracker::kMaxDuplicateTsnReported + 10; ++i) {
TSN tsn(11 + i);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->Observe(tsn, AnyDataChunk::ImmediateAckFlag(false));
tracker_->Observe(tsn, AnyDataChunk::ImmediateAckFlag(false));
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
}
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
EXPECT_THAT(sack.duplicate_tsns(),
SizeIs(DataTracker::kMaxDuplicateTsnReported));
}
TEST_F(DataTrackerTest, LimitsNumberOfGapAckBlocksReported) {
for (size_t i = 0; i < DataTracker::kMaxGapAckBlocksReported + 10; ++i) {
TSN tsn(11 + i * 2);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->Observe(tsn, AnyDataChunk::ImmediateAckFlag(false));
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
}
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Limit the size of generated SACK chunks Today, there is no actual limit on how large a SACK chunk can be. And having limits is good to be able to stay within the MTU. This commit adds a limit to the number of reported duplicate TSNs as well as the number of reported gap-ack-blocks in a SACK chunk. These limits are never expected to be reached in a real-life situation. Bug: webrtc:12614 Change-Id: Ib2c143714a214cd3d961e8a52dac26a04b909b80 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219464 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34108}
2021-05-19 14:03:22 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack.gap_ack_blocks(),
SizeIs(DataTracker::kMaxGapAckBlocksReported));
}
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
TEST_F(DataTrackerTest, SendsSackForFirstPacketObserved) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
}
TEST_F(DataTrackerTest, SendsSackEverySecondPacketWhenThereIsNoPacketLoss) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_TRUE(timer_->is_running());
Observer({13});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({14});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_TRUE(timer_->is_running());
Observer({15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
}
TEST_F(DataTrackerTest, SendsSackEveryPacketOnPacketLoss) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({13});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({14});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({15});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({16});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
// Fill the hole.
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_TRUE(timer_->is_running());
// Goes back to every second packet
Observer({17});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({18});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_TRUE(timer_->is_running());
}
TEST_F(DataTrackerTest, SendsSackOnDuplicateDataChunks) {
Observer({11});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({11}, /*expect_as_duplicate=*/true);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_TRUE(timer_->is_running());
// Goes back to every second packet
Observer({13});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
// Duplicate again
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({12}, /*expect_as_duplicate=*/true);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
dcsctp: Add more unit tests for DataTracker There were some missing unit tests that are now written. When doing this, it was found that SACKs weren't sent for duplicate received chunks, which they should be according to the spec. Bug: webrtc:12614 Change-Id: I8296473c0c8cbaf0329785de95e9b9945f254339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220607 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34165}
2021-05-28 17:21:39 +02:00
EXPECT_FALSE(timer_->is_running());
}
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
TEST_F(DataTrackerTest, GapAckBlockAddSingleBlock) {
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2)));
}
TEST_F(DataTrackerTest, GapAckBlockAddsAnother) {
Observer({12});
Observer({14});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2),
SackChunk::GapAckBlock(4, 4)));
}
TEST_F(DataTrackerTest, GapAckBlockAddsDuplicate) {
Observer({12});
dcsctp: Don't reassemble already received chunks This is a solution to some problems that have been found locally when running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has found a way to trigger a consistency check to fail when a client intentionally sends different messages - unordered and ordered - using the same TSNs. As the reassembly queue has different handling of ordered and unordered chunks due to how they are reassembled, it will not notice if it receives two different chunks with the same TSN. They will both go to their respective reassembly streams, as those are separate by design. The data tracker - which keeps track of all received DATA chunks as it needs to generate SACKs, has a global understanding of all received chunks. By having it indicate if this is a duplicate received chunk, the socket can avoid forwarding both chunks to the reassembly queue; only one chunk will get there. Bug: None Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36316}
2022-03-20 19:59:03 +01:00
Observer({12}, /*expect_as_duplicate=*/true);
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 2)));
EXPECT_THAT(sack.duplicate_tsns(), ElementsAre(TSN(12)));
}
TEST_F(DataTrackerTest, GapAckBlockExpandsToRight) {
Observer({12});
Observer({13});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 3)));
}
TEST_F(DataTrackerTest, GapAckBlockExpandsToRightWithOther) {
Observer({12});
Observer({20});
Observer({30});
Observer({21});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(),
ElementsAre(SackChunk::GapAckBlock(2, 2), //
SackChunk::GapAckBlock(10, 11), //
SackChunk::GapAckBlock(20, 20)));
}
TEST_F(DataTrackerTest, GapAckBlockExpandsToLeft) {
Observer({13});
Observer({12});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(), ElementsAre(SackChunk::GapAckBlock(2, 3)));
}
TEST_F(DataTrackerTest, GapAckBlockExpandsToLeftWithOther) {
Observer({12});
Observer({21});
Observer({30});
Observer({20});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(),
ElementsAre(SackChunk::GapAckBlock(2, 2), //
SackChunk::GapAckBlock(10, 11), //
SackChunk::GapAckBlock(20, 20)));
}
TEST_F(DataTrackerTest, GapAckBlockExpandsToLRightAndMerges) {
Observer({12});
Observer({20});
Observer({22});
Observer({30});
Observer({21});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(sack.gap_ack_blocks(),
ElementsAre(SackChunk::GapAckBlock(2, 2), //
SackChunk::GapAckBlock(10, 12), //
SackChunk::GapAckBlock(20, 20)));
}
TEST_F(DataTrackerTest, GapAckBlockMergesManyBlocksIntoOne) {
Observer({22});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12)));
Observer({30});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12), //
SackChunk::GapAckBlock(20, 20)));
Observer({24});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12), //
SackChunk::GapAckBlock(14, 14), //
SackChunk::GapAckBlock(20, 20)));
Observer({28});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12), //
SackChunk::GapAckBlock(14, 14), //
SackChunk::GapAckBlock(18, 18), //
SackChunk::GapAckBlock(20, 20)));
Observer({26});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12), //
SackChunk::GapAckBlock(14, 14), //
SackChunk::GapAckBlock(16, 16), //
SackChunk::GapAckBlock(18, 18), //
SackChunk::GapAckBlock(20, 20)));
Observer({29});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 12), //
SackChunk::GapAckBlock(14, 14), //
SackChunk::GapAckBlock(16, 16), //
SackChunk::GapAckBlock(18, 20)));
Observer({23});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 14), //
SackChunk::GapAckBlock(16, 16), //
SackChunk::GapAckBlock(18, 20)));
Observer({27});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 14), //
SackChunk::GapAckBlock(16, 20)));
Observer({25});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(12, 20)));
Observer({20});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(10, 10), //
SackChunk::GapAckBlock(12, 20)));
Observer({32});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(10, 10), //
SackChunk::GapAckBlock(12, 20), //
SackChunk::GapAckBlock(22, 22)));
Observer({21});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(10, 20), //
SackChunk::GapAckBlock(22, 22)));
Observer({31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(10, 22)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveBeforeCumAckTsn) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(8));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(10));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(2, 4), //
SackChunk::GapAckBlock(10, 12),
SackChunk::GapAckBlock(20, 21)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveBeforeFirstBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(11));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(6, 8), //
SackChunk::GapAckBlock(16, 17)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveAtBeginningOfFirstBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(12));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(6, 8), //
SackChunk::GapAckBlock(16, 17)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveAtMiddleOfFirstBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(13));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(6, 8), //
SackChunk::GapAckBlock(16, 17)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveAtEndOfFirstBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(14));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(14));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(6, 8), //
SackChunk::GapAckBlock(16, 17)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveRightAfterFirstBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(18));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(18));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(2, 4), //
SackChunk::GapAckBlock(12, 13)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveRightBeforeSecondBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(19));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(22));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(8, 9)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveRightAtStartOfSecondBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(20));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(22));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(8, 9)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveRightAtMiddleOfSecondBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(21));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(22));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(8, 9)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveRightAtEndOfSecondBlock) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(22));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(22));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(),
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
ElementsAre(SackChunk::GapAckBlock(8, 9)));
}
TEST_F(DataTrackerTest, GapAckBlockRemoveeFarAfterAllBlocks) {
Observer({12, 13, 14, 20, 21, 22, 30, 31});
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
tracker_->HandleForwardTsn(TSN(40));
EXPECT_EQ(tracker_->CreateSelectiveAck(kArwnd).cumulative_tsn_ack(), TSN(40));
EXPECT_THAT(tracker_->CreateSelectiveAck(kArwnd).gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest, HandoverEmpty) {
HandoverTracker();
Observer({11});
SackChunk sack = tracker_->CreateSelectiveAck(kArwnd);
EXPECT_EQ(sack.cumulative_tsn_ack(), TSN(11));
EXPECT_THAT(sack.gap_ack_blocks(), IsEmpty());
}
TEST_F(DataTrackerTest,
HandoverWhileSendingSackEverySecondPacketWhenThereIsNoPacketLoss) {
Observer({11});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
HandoverTracker();
Observer({12});
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
Observer({13});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
EXPECT_FALSE(timer_->is_running());
Observer({14});
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
EXPECT_TRUE(timer_->is_running());
Observer({15});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
EXPECT_FALSE(timer_->is_running());
dcsctp: Optimize SACK generation Before this CL, a SACK was generated from scratch based on information about each received fragment, to generate correct gap-ack-blocks. When there was a lot of data in the data tracker (due to packet loss), this took considerate time, as generating a SACK was O(N), where N is the amount of fragments in the data tracker. By instead having precomputed gap-ack-blocks that are continuously updated, generating a SACK is much faster and the memory usage goes down a bit as well. Bug: webrtc:12799 Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34171}
2021-05-29 21:20:12 +02:00
}
dcsctp: implement handover in DataTracker Bug: webrtc:13154 Change-Id: Ia8c41dcffd95dafd904ee630f2131b575fe833dd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231955 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34996}
2021-09-14 22:08:53 +02:00
TEST_F(DataTrackerTest, HandoverWhileSendingSackEveryPacketOnPacketLoss) {
Observer({11});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
Observer({13});
EXPECT_EQ(tracker_->GetHandoverReadiness(),
HandoverReadinessStatus().Add(
HandoverUnreadinessReason::kDataTrackerTsnBlocksPending));
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
Observer({14});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
EXPECT_EQ(tracker_->GetHandoverReadiness(),
HandoverReadinessStatus(
HandoverUnreadinessReason::kDataTrackerTsnBlocksPending));
Observer({15});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
Observer({16});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
// Fill the hole.
Observer({12});
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
// Goes back to every second packet
Observer({17});
tracker_->ObservePacketEnd();
EXPECT_TRUE(tracker_->ShouldSendAck());
HandoverTracker();
Observer({18});
tracker_->ObservePacketEnd();
EXPECT_FALSE(tracker_->ShouldSendAck());
EXPECT_TRUE(timer_->is_running());
}
dcsctp: Add Data Tracker The Data Tracker's purpose is to keep track of all received DATA chunks and to ACK/NACK that data, by generating SACK chunks reflecting its view of what has been received and what has been lost. It also contains logic for _when_ to send the SACKs, as that's different depending on e.g. packet loss. Generally, SACKs are sent every second packet on a connection with no packet loss, and can also be sent on a delayed timer. In case partial reliability is used, and the transmitter has decided that some data shouldn't be retransmitted, it will send a FORWARD-TSN chunk, which this class also handles, by "forgetting" about those chunks. Bug: webrtc:12614 Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33676}
2021-04-01 23:36:03 +02:00
} // namespace
} // namespace dcsctp
Reference in New Issue Copy Permalink