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

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

803 lines
32 KiB
C++
Raw Normal View History

dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +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/socket/stream_reset_handler.h"
#include <array>
#include <cstdint>
#include <memory>
#include <type_traits>
#include <vector>
#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 Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
#include "net/dcsctp/common/internal_types.h"
#include "net/dcsctp/packet/chunk/reconfig_chunk.h"
#include "net/dcsctp/packet/parameter/incoming_ssn_reset_request_parameter.h"
#include "net/dcsctp/packet/parameter/outgoing_ssn_reset_request_parameter.h"
#include "net/dcsctp/packet/parameter/parameter.h"
#include "net/dcsctp/packet/parameter/reconfiguration_response_parameter.h"
#include "net/dcsctp/public/dcsctp_message.h"
#include "net/dcsctp/rx/data_tracker.h"
#include "net/dcsctp/rx/reassembly_queue.h"
#include "net/dcsctp/socket/mock_context.h"
#include "net/dcsctp/socket/mock_dcsctp_socket_callbacks.h"
#include "net/dcsctp/testing/data_generator.h"
#include "net/dcsctp/testing/testing_macros.h"
#include "net/dcsctp/timer/timer.h"
#include "net/dcsctp/tx/mock_send_queue.h"
#include "net/dcsctp/tx/retransmission_queue.h"
#include "rtc_base/gunit.h"
#include "test/gmock.h"
namespace dcsctp {
namespace {
using ::testing::IsEmpty;
using ::testing::NiceMock;
using ::testing::Return;
using ::testing::SizeIs;
using ::testing::UnorderedElementsAre;
using ResponseResult = ReconfigurationResponseParameter::Result;
constexpr TSN kMyInitialTsn = MockContext::MyInitialTsn();
constexpr ReconfigRequestSN kMyInitialReqSn = ReconfigRequestSN(*kMyInitialTsn);
constexpr TSN kPeerInitialTsn = MockContext::PeerInitialTsn();
constexpr ReconfigRequestSN kPeerInitialReqSn =
ReconfigRequestSN(*kPeerInitialTsn);
constexpr uint32_t kArwnd = 131072;
constexpr DurationMs kRto = DurationMs(250);
constexpr std::array<uint8_t, 4> kShortPayload = {1, 2, 3, 4};
MATCHER_P3(SctpMessageIs, stream_id, ppid, expected_payload, "") {
if (arg.stream_id() != stream_id) {
*result_listener << "the stream_id is " << *arg.stream_id();
return false;
}
if (arg.ppid() != ppid) {
*result_listener << "the ppid is " << *arg.ppid();
return false;
}
if (std::vector<uint8_t>(arg.payload().begin(), arg.payload().end()) !=
std::vector<uint8_t>(expected_payload.begin(), expected_payload.end())) {
*result_listener << "the payload is wrong";
return false;
}
return true;
}
TSN AddTo(TSN tsn, int delta) {
return TSN(*tsn + delta);
}
ReconfigRequestSN AddTo(ReconfigRequestSN req_sn, int delta) {
return ReconfigRequestSN(*req_sn + delta);
}
class StreamResetHandlerTest : public testing::Test {
protected:
StreamResetHandlerTest()
: ctx_(&callbacks_),
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 callbacks_.CreateTimeout(precision);
}),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
delayed_ack_timer_(timer_manager_.CreateTimer(
"test/delayed_ack",
[]() { return absl::nullopt; },
TimerOptions(DurationMs(0)))),
t3_rtx_timer_(timer_manager_.CreateTimer(
"test/t3_rtx",
[]() { return absl::nullopt; },
TimerOptions(DurationMs(0)))),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_(std::make_unique<DataTracker>("log: ",
delayed_ack_timer_.get(),
kPeerInitialTsn)),
reasm_(std::make_unique<ReassemblyQueue>("log: ",
kPeerInitialTsn,
kArwnd)),
retransmission_queue_(std::make_unique<RetransmissionQueue>(
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
"",
dcsctp: Generate lifecycle events This adds the final piece, which makes the socket and the retransmission queue generate the callbacks. Bug: webrtc:5696 Change-Id: I1e28c98e9660bd018e817a3ba0fa6b03940fcd33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264125 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37455}
2022-05-27 14:44:57 +02:00
&callbacks_,
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
kMyInitialTsn,
kArwnd,
producer_,
[](DurationMs rtt_ms) {},
[]() {},
*t3_rtx_timer_,
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
DcSctpOptions())),
handler_(
std::make_unique<StreamResetHandler>("log: ",
&ctx_,
&timer_manager_,
data_tracker_.get(),
reasm_.get(),
retransmission_queue_.get())) {
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_CALL(ctx_, current_rto).WillRepeatedly(Return(kRto));
}
void AdvanceTime(DurationMs duration) {
callbacks_.AdvanceTime(kRto);
dcsctp: Expire timers just before triggering them In real life, when a Timeout expires, the caller is supposed to call DcSctpSocket::HandleTimeout directly, as the Timeout that just expired is stopped (it just expired), but the Timer still believes it's running. The system is not in a consistent state. In tests, all timeouts were evaluated at the same time, which, if two timeouts expired at the same time, would put them both as "not running", and with their timers believing they were running. So if you would do any operation on a timer whose timeout had just expired, the timeout would assert saying that "you can't stop a stopped timeout" or similar. This isn't relevant in non-test scenarios. Solved by expiring timeouts one by one. Bug: webrtc:12614 Change-Id: I79d006f4d3e96854d77cec3eb0080aa23b8569cb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217560 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33925}
2021-05-05 14:00:50 +02:00
for (;;) {
absl::optional<TimeoutID> timeout_id = callbacks_.GetNextExpiredTimeout();
if (!timeout_id.has_value()) {
break;
}
timer_manager_.HandleTimeout(*timeout_id);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
}
// Handles the passed in RE-CONFIG `chunk` and returns the responses
// that are sent in the response RE-CONFIG.
std::vector<ReconfigurationResponseParameter> HandleAndCatchResponse(
ReConfigChunk chunk) {
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(std::move(chunk));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
std::vector<uint8_t> payload = callbacks_.ConsumeSentPacket();
if (payload.empty()) {
EXPECT_TRUE(false);
return {};
}
std::vector<ReconfigurationResponseParameter> responses;
absl::optional<SctpPacket> p = SctpPacket::Parse(payload);
if (!p.has_value()) {
EXPECT_TRUE(false);
return {};
}
if (p->descriptors().size() != 1) {
EXPECT_TRUE(false);
return {};
}
absl::optional<ReConfigChunk> response_chunk =
ReConfigChunk::Parse(p->descriptors()[0].data);
if (!response_chunk.has_value()) {
EXPECT_TRUE(false);
return {};
}
for (const auto& desc : response_chunk->parameters().descriptors()) {
if (desc.type == ReconfigurationResponseParameter::kType) {
absl::optional<ReconfigurationResponseParameter> response =
ReconfigurationResponseParameter::Parse(desc.data);
if (!response.has_value()) {
EXPECT_TRUE(false);
return {};
}
responses.emplace_back(*std::move(response));
}
}
return responses;
}
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
void PerformHandover() {
EXPECT_TRUE(handler_->GetHandoverReadiness().IsReady());
EXPECT_TRUE(data_tracker_->GetHandoverReadiness().IsReady());
EXPECT_TRUE(reasm_->GetHandoverReadiness().IsReady());
EXPECT_TRUE(retransmission_queue_->GetHandoverReadiness().IsReady());
DcSctpSocketHandoverState state;
handler_->AddHandoverState(state);
data_tracker_->AddHandoverState(state);
reasm_->AddHandoverState(state);
retransmission_queue_->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);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_ = std::make_unique<DataTracker>(
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
"log: ", delayed_ack_timer_.get(), kPeerInitialTsn);
data_tracker_->RestoreFromState(state);
reasm_ =
std::make_unique<ReassemblyQueue>("log: ", kPeerInitialTsn, kArwnd);
reasm_->RestoreFromState(state);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
retransmission_queue_ = std::make_unique<RetransmissionQueue>(
dcsctp: Generate lifecycle events This adds the final piece, which makes the socket and the retransmission queue generate the callbacks. Bug: webrtc:5696 Change-Id: I1e28c98e9660bd018e817a3ba0fa6b03940fcd33 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264125 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#37455}
2022-05-27 14:44:57 +02:00
"", &callbacks_, kMyInitialTsn, kArwnd, producer_,
[](DurationMs rtt_ms) {}, []() {}, *t3_rtx_timer_, DcSctpOptions(),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
/*supports_partial_reliability=*/true,
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
/*use_message_interleaving=*/false);
retransmission_queue_->RestoreFromState(state);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_ = std::make_unique<StreamResetHandler>(
"log: ", &ctx_, &timer_manager_, data_tracker_.get(), reasm_.get(),
retransmission_queue_.get(), &state);
}
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
DataGenerator gen_;
NiceMock<MockDcSctpSocketCallbacks> callbacks_;
NiceMock<MockContext> ctx_;
NiceMock<MockSendQueue> producer_;
TimerManager timer_manager_;
std::unique_ptr<Timer> delayed_ack_timer_;
std::unique_ptr<Timer> t3_rtx_timer_;
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
std::unique_ptr<DataTracker> data_tracker_;
std::unique_ptr<ReassemblyQueue> reasm_;
std::unique_ptr<RetransmissionQueue> retransmission_queue_;
std::unique_ptr<StreamResetHandler> handler_;
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
};
TEST_F(StreamResetHandlerTest, ChunkWithNoParametersReturnsError) {
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_CALL(callbacks_, OnError).Times(1);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(ReConfigChunk(Parameters()));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, ChunkWithInvalidParametersReturnsError) {
Parameters::Builder builder;
// Two OutgoingSSNResetRequestParameter in a RE-CONFIG is not valid.
builder.Add(OutgoingSSNResetRequestParameter(ReconfigRequestSN(1),
ReconfigRequestSN(10),
kPeerInitialTsn, {StreamID(1)}));
builder.Add(OutgoingSSNResetRequestParameter(ReconfigRequestSN(2),
ReconfigRequestSN(10),
kPeerInitialTsn, {StreamID(2)}));
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_CALL(callbacks_, OnError).Times(1);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(ReConfigChunk(builder.Build()));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, FailToDeliverWithoutResettingStream) {
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(kPeerInitialTsn, gen_.Ordered({1, 2, 3, 4}, "BE"));
reasm_->Add(AddTo(kPeerInitialTsn, 1), gen_.Ordered({1, 2, 3, 4}, "BE"));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_->Observe(kPeerInitialTsn);
data_tracker_->Observe(AddTo(kPeerInitialTsn, 1));
EXPECT_THAT(reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(
SctpMessageIs(StreamID(1), PPID(53), kShortPayload),
SctpMessageIs(StreamID(1), PPID(53), kShortPayload)));
gen_.ResetStream();
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 2), gen_.Ordered({1, 2, 3, 4}, "BE"));
EXPECT_THAT(reasm_->FlushMessages(), IsEmpty());
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, ResetStreamsNotDeferred) {
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(kPeerInitialTsn, gen_.Ordered({1, 2, 3, 4}, "BE"));
reasm_->Add(AddTo(kPeerInitialTsn, 1), gen_.Ordered({1, 2, 3, 4}, "BE"));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_->Observe(kPeerInitialTsn);
data_tracker_->Observe(AddTo(kPeerInitialTsn, 1));
EXPECT_THAT(reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(
SctpMessageIs(StreamID(1), PPID(53), kShortPayload),
SctpMessageIs(StreamID(1), PPID(53), kShortPayload)));
Parameters::Builder builder;
builder.Add(OutgoingSSNResetRequestParameter(
kPeerInitialReqSn, ReconfigRequestSN(3), AddTo(kPeerInitialTsn, 1),
{StreamID(1)}));
std::vector<ReconfigurationResponseParameter> responses =
HandleAndCatchResponse(ReConfigChunk(builder.Build()));
EXPECT_THAT(responses, SizeIs(1));
EXPECT_EQ(responses[0].result(), ResponseResult::kSuccessPerformed);
gen_.ResetStream();
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 2), gen_.Ordered({1, 2, 3, 4}, "BE"));
EXPECT_THAT(reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(
SctpMessageIs(StreamID(1), PPID(53), kShortPayload)));
}
TEST_F(StreamResetHandlerTest, ResetStreamsDeferred) {
DataGeneratorOptions opts;
opts.message_id = MID(0);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(kPeerInitialTsn, gen_.Ordered({1, 2, 3, 4}, "BE", opts));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
opts.message_id = MID(1);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 1),
gen_.Ordered({1, 2, 3, 4}, "BE", opts));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_->Observe(kPeerInitialTsn);
data_tracker_->Observe(AddTo(kPeerInitialTsn, 1));
EXPECT_THAT(reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(
SctpMessageIs(StreamID(1), PPID(53), kShortPayload),
SctpMessageIs(StreamID(1), PPID(53), kShortPayload)));
Parameters::Builder builder;
builder.Add(OutgoingSSNResetRequestParameter(
kPeerInitialReqSn, ReconfigRequestSN(3), AddTo(kPeerInitialTsn, 3),
{StreamID(1)}));
std::vector<ReconfigurationResponseParameter> responses =
HandleAndCatchResponse(ReConfigChunk(builder.Build()));
EXPECT_THAT(responses, SizeIs(1));
EXPECT_EQ(responses[0].result(), ResponseResult::kInProgress);
opts.message_id = MID(1);
opts.ppid = PPID(5);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 5),
gen_.Ordered({1, 2, 3, 4}, "BE", opts));
reasm_->MaybeResetStreamsDeferred(AddTo(kPeerInitialTsn, 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
opts.message_id = MID(0);
opts.ppid = PPID(4);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 4),
gen_.Ordered({1, 2, 3, 4}, "BE", opts));
reasm_->MaybeResetStreamsDeferred(AddTo(kPeerInitialTsn, 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
opts.message_id = MID(3);
opts.ppid = PPID(3);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 3),
gen_.Ordered({1, 2, 3, 4}, "BE", opts));
reasm_->MaybeResetStreamsDeferred(AddTo(kPeerInitialTsn, 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
opts.message_id = MID(2);
opts.ppid = PPID(2);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(AddTo(kPeerInitialTsn, 2),
gen_.Ordered({1, 2, 3, 4}, "BE", opts));
reasm_->MaybeResetStreamsDeferred(AddTo(kPeerInitialTsn, 5));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_THAT(
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(SctpMessageIs(StreamID(1), PPID(2), kShortPayload),
SctpMessageIs(StreamID(1), PPID(3), kShortPayload),
SctpMessageIs(StreamID(1), PPID(4), kShortPayload),
SctpMessageIs(StreamID(1), PPID(5), kShortPayload)));
}
TEST_F(StreamResetHandlerTest, SendOutgoingRequestDirectly) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig->parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req.request_sequence_number(), kMyInitialReqSn);
EXPECT_EQ(req.sender_last_assigned_tsn(),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
TSN(*retransmission_queue_->next_tsn() - 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_THAT(req.stream_ids(), UnorderedElementsAre(StreamID(42)));
}
TEST_F(StreamResetHandlerTest, ResetMultipleStreamsInOneRequest) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(40)));
EXPECT_CALL(producer_, PrepareResetStream(StreamID(41)));
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42))).Times(2);
EXPECT_CALL(producer_, PrepareResetStream(StreamID(43)));
EXPECT_CALL(producer_, PrepareResetStream(StreamID(44)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
handler_->ResetStreams(
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
std::vector<StreamID>({StreamID(43), StreamID(44), StreamID(41)}));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42), StreamID(40)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(
std::vector<StreamID>({StreamID(40), StreamID(41), StreamID(42),
StreamID(43), StreamID(44)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig->parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req.request_sequence_number(), kMyInitialReqSn);
EXPECT_EQ(req.sender_last_assigned_tsn(),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
TSN(*retransmission_queue_->next_tsn() - 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_THAT(req.stream_ids(),
UnorderedElementsAre(StreamID(40), StreamID(41), StreamID(42),
StreamID(43), StreamID(44)));
}
TEST_F(StreamResetHandlerTest, SendOutgoingRequestDeferred) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset())
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
.WillOnce(Return(false))
.WillOnce(Return(false))
.WillOnce(Return(true));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
EXPECT_FALSE(handler_->MakeStreamResetRequest().has_value());
EXPECT_FALSE(handler_->MakeStreamResetRequest().has_value());
EXPECT_TRUE(handler_->MakeStreamResetRequest().has_value());
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, SendOutgoingResettingOnPositiveResponse) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig->parameters().get<OutgoingSSNResetRequestParameter>());
Parameters::Builder builder;
builder.Add(ReconfigurationResponseParameter(
req.request_sequence_number(), ResponseResult::kSuccessPerformed));
ReConfigChunk response_reconfig(builder.Build());
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, CommitResetStreams);
EXPECT_CALL(producer_, RollbackResetStreams).Times(0);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
// Processing a response shouldn't result in sending anything.
EXPECT_CALL(callbacks_, OnError).Times(0);
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(std::move(response_reconfig));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, SendOutgoingResetRollbackOnError) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig->parameters().get<OutgoingSSNResetRequestParameter>());
Parameters::Builder builder;
builder.Add(ReconfigurationResponseParameter(
req.request_sequence_number(), ResponseResult::kErrorBadSequenceNumber));
ReConfigChunk response_reconfig(builder.Build());
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, CommitResetStreams).Times(0);
EXPECT_CALL(producer_, RollbackResetStreams);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
// Only requests should result in sending responses.
EXPECT_CALL(callbacks_, OnError).Times(0);
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(std::move(response_reconfig));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
}
TEST_F(StreamResetHandlerTest, SendOutgoingResetRetransmitOnInProgress) {
static constexpr StreamID kStreamToReset = StreamID(42);
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(kStreamToReset));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({kStreamToReset}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({kStreamToReset})));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig1 = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig1.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req1,
reconfig1->parameters().get<OutgoingSSNResetRequestParameter>());
// Simulate that the peer responded "In Progress".
Parameters::Builder builder;
builder.Add(ReconfigurationResponseParameter(req1.request_sequence_number(),
ResponseResult::kInProgress));
ReConfigChunk response_reconfig(builder.Build());
EXPECT_CALL(producer_, CommitResetStreams()).Times(0);
EXPECT_CALL(producer_, RollbackResetStreams()).Times(0);
// Processing a response shouldn't result in sending anything.
EXPECT_CALL(callbacks_, OnError).Times(0);
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(std::move(response_reconfig));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
// Let some time pass, so that the reconfig timer expires, and retries the
// same request.
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(1);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
AdvanceTime(kRto);
std::vector<uint8_t> payload = callbacks_.ConsumeSentPacket();
ASSERT_FALSE(payload.empty());
ASSERT_HAS_VALUE_AND_ASSIGN(SctpPacket packet, SctpPacket::Parse(payload));
ASSERT_THAT(packet.descriptors(), SizeIs(1));
ASSERT_HAS_VALUE_AND_ASSIGN(
ReConfigChunk reconfig2,
ReConfigChunk::Parse(packet.descriptors()[0].data));
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req2,
reconfig2.parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req2.request_sequence_number(),
AddTo(req1.request_sequence_number(), 1));
EXPECT_THAT(req2.stream_ids(), UnorderedElementsAre(kStreamToReset));
}
TEST_F(StreamResetHandlerTest, ResetWhileRequestIsSentWillQueue) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig1 = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig1.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req1,
reconfig1->parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req1.request_sequence_number(), kMyInitialReqSn);
EXPECT_EQ(req1.sender_last_assigned_tsn(),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
AddTo(retransmission_queue_->next_tsn(), -1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_THAT(req1.stream_ids(), UnorderedElementsAre(StreamID(42)));
// Streams reset while the request is in-flight will be queued.
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(41)));
EXPECT_CALL(producer_, PrepareResetStream(StreamID(43)));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
StreamID stream_ids[] = {StreamID(41), StreamID(43)};
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(stream_ids);
EXPECT_EQ(handler_->MakeStreamResetRequest(), absl::nullopt);
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
Parameters::Builder builder;
builder.Add(ReconfigurationResponseParameter(
req1.request_sequence_number(), ResponseResult::kSuccessPerformed));
ReConfigChunk response_reconfig(builder.Build());
EXPECT_CALL(producer_, CommitResetStreams()).Times(1);
EXPECT_CALL(producer_, RollbackResetStreams()).Times(0);
// Processing a response shouldn't result in sending anything.
EXPECT_CALL(callbacks_, OnError).Times(0);
dcsctp: Add API to indicate packet send status Before this change, there was no way for a client to indicate to the dcSCTP library if a packet that was supposed to be sent, was actually sent. It was assumed that it always was. To handle temporary failures better, such as retrying to send packets that failed to be sent when the send buffer was full, this information is propagated to the library. Note that this change only covers the API and adaptations to clients. The actual implementation to make use of this information is done as a follow-up change. Bug: webrtc:12943 Change-Id: I8f9c62e17f1de1566fa6b0f13a57a3db9f4e7684 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228563 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34767}
2021-08-12 15:21:25 +02:00
EXPECT_CALL(callbacks_, SendPacketWithStatus).Times(0);
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->HandleReConfig(std::move(response_reconfig));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
// Response has been processed. A new request can be sent.
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(41), StreamID(43)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig2 = handler_->MakeStreamResetRequest();
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
ASSERT_TRUE(reconfig2.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req2,
reconfig2->parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req2.request_sequence_number(), AddTo(kMyInitialReqSn, 1));
EXPECT_EQ(req2.sender_last_assigned_tsn(),
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
TSN(*retransmission_queue_->next_tsn() - 1));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
EXPECT_THAT(req2.stream_ids(),
UnorderedElementsAre(StreamID(41), StreamID(43)));
}
TEST_F(StreamResetHandlerTest, SendIncomingResetJustReturnsNothingPerformed) {
Parameters::Builder builder;
builder.Add(
IncomingSSNResetRequestParameter(kPeerInitialReqSn, {StreamID(1)}));
std::vector<ReconfigurationResponseParameter> responses =
HandleAndCatchResponse(ReConfigChunk(builder.Build()));
ASSERT_THAT(responses, SizeIs(1));
EXPECT_THAT(responses[0].response_sequence_number(), kPeerInitialReqSn);
EXPECT_THAT(responses[0].result(), ResponseResult::kSuccessNothingToDo);
}
TEST_F(StreamResetHandlerTest, SendSameRequestTwiceReturnsNothingToDo) {
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
reasm_->Add(kPeerInitialTsn, gen_.Ordered({1, 2, 3, 4}, "BE"));
reasm_->Add(AddTo(kPeerInitialTsn, 1), gen_.Ordered({1, 2, 3, 4}, "BE"));
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
data_tracker_->Observe(kPeerInitialTsn);
data_tracker_->Observe(AddTo(kPeerInitialTsn, 1));
EXPECT_THAT(reasm_->FlushMessages(),
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
UnorderedElementsAre(
SctpMessageIs(StreamID(1), PPID(53), kShortPayload),
SctpMessageIs(StreamID(1), PPID(53), kShortPayload)));
Parameters::Builder builder1;
builder1.Add(OutgoingSSNResetRequestParameter(
kPeerInitialReqSn, ReconfigRequestSN(3), AddTo(kPeerInitialTsn, 1),
{StreamID(1)}));
std::vector<ReconfigurationResponseParameter> responses1 =
HandleAndCatchResponse(ReConfigChunk(builder1.Build()));
EXPECT_THAT(responses1, SizeIs(1));
EXPECT_EQ(responses1[0].result(), ResponseResult::kSuccessPerformed);
Parameters::Builder builder2;
builder2.Add(OutgoingSSNResetRequestParameter(
kPeerInitialReqSn, ReconfigRequestSN(3), AddTo(kPeerInitialTsn, 1),
{StreamID(1)}));
std::vector<ReconfigurationResponseParameter> responses2 =
HandleAndCatchResponse(ReConfigChunk(builder2.Build()));
EXPECT_THAT(responses2, SizeIs(1));
EXPECT_EQ(responses2[0].result(), ResponseResult::kSuccessNothingToDo);
}
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
TEST_F(StreamResetHandlerTest,
HandoverIsAllowedOnlyWhenNoStreamIsBeingOrWillBeReset) {
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
EXPECT_EQ(
handler_->GetHandoverReadiness(),
HandoverReadinessStatus(HandoverUnreadinessReason::kPendingStreamReset));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset())
.WillOnce(Return(true))
.WillOnce(Return(false));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
ASSERT_TRUE(handler_->MakeStreamResetRequest().has_value());
EXPECT_EQ(handler_->GetHandoverReadiness(),
HandoverReadinessStatus(
HandoverUnreadinessReason::kPendingStreamResetRequest));
// Reset more streams while the request is in-flight.
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(41)));
EXPECT_CALL(producer_, PrepareResetStream(StreamID(43)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
StreamID stream_ids[] = {StreamID(41), StreamID(43)};
handler_->ResetStreams(stream_ids);
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
EXPECT_EQ(handler_->GetHandoverReadiness(),
HandoverReadinessStatus()
.Add(HandoverUnreadinessReason::kPendingStreamResetRequest)
.Add(HandoverUnreadinessReason::kPendingStreamReset));
// Processing a response to first request.
EXPECT_CALL(producer_, CommitResetStreams()).Times(1);
handler_->HandleReConfig(
ReConfigChunk(Parameters::Builder()
.Add(ReconfigurationResponseParameter(
kMyInitialReqSn, ResponseResult::kSuccessPerformed))
.Build()));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
EXPECT_EQ(
handler_->GetHandoverReadiness(),
HandoverReadinessStatus(HandoverUnreadinessReason::kPendingStreamReset));
// Second request can be sent.
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset())
.WillOnce(Return(true))
.WillOnce(Return(false));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(41), StreamID(43)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
ASSERT_TRUE(handler_->MakeStreamResetRequest().has_value());
EXPECT_EQ(handler_->GetHandoverReadiness(),
HandoverReadinessStatus(
HandoverUnreadinessReason::kPendingStreamResetRequest));
// Processing a response to second request.
EXPECT_CALL(producer_, CommitResetStreams()).Times(1);
handler_->HandleReConfig(ReConfigChunk(
Parameters::Builder()
.Add(ReconfigurationResponseParameter(
AddTo(kMyInitialReqSn, 1), ResponseResult::kSuccessPerformed))
.Build()));
// Seconds response has been processed. No pending resets.
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(false));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
EXPECT_TRUE(handler_->GetHandoverReadiness().IsReady());
}
TEST_F(StreamResetHandlerTest, HandoverInInitialState) {
PerformHandover();
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
absl::optional<ReConfigChunk> reconfig = handler_->MakeStreamResetRequest();
ASSERT_TRUE(reconfig.has_value());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig->parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req.request_sequence_number(), kMyInitialReqSn);
EXPECT_EQ(req.sender_last_assigned_tsn(),
TSN(*retransmission_queue_->next_tsn() - 1));
EXPECT_THAT(req.stream_ids(), UnorderedElementsAre(StreamID(42)));
}
TEST_F(StreamResetHandlerTest, HandoverAfterHavingResetOneStream) {
// Reset one stream
{
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(42)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(42)}));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset())
.WillOnce(Return(true))
.WillOnce(Return(false));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(42)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
ASSERT_HAS_VALUE_AND_ASSIGN(ReConfigChunk reconfig,
handler_->MakeStreamResetRequest());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig.parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req.request_sequence_number(), kMyInitialReqSn);
EXPECT_EQ(req.sender_last_assigned_tsn(),
TSN(*retransmission_queue_->next_tsn() - 1));
EXPECT_THAT(req.stream_ids(), UnorderedElementsAre(StreamID(42)));
EXPECT_CALL(producer_, CommitResetStreams()).Times(1);
handler_->HandleReConfig(
ReConfigChunk(Parameters::Builder()
.Add(ReconfigurationResponseParameter(
req.request_sequence_number(),
ResponseResult::kSuccessPerformed))
.Build()));
}
PerformHandover();
// Reset another stream after handover
{
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, PrepareResetStream(StreamID(43)));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
handler_->ResetStreams(std::vector<StreamID>({StreamID(43)}));
dcsctp: Handle rapid closing of streams When streams were to be reset, but there was already an ongoing stream reset command in-flight, those streams wouldn't be properly reset. When multiple streams were reset close to each other (within an RTT), some streams would not have their SSNs reset, which resulted in the stream resuming the SSN sequence. This could result in ordered streams not delivering all messages as the receiver wouldn't deliver any messages with SSN different from the expected SSN=0. In WebRTC data channels, this would be triggered if multiple channels were closed at roughly the same time, then re-opened, and continued to be used in ordered mode. Unordered messages would still be delivered, but the stream state could be wrong as the DATA_CHANNEL_ACK message is sent ordered, and possibly not delivered. There were unit tests for this, but not on the socket level using real components, but just on the stream reset handler using mocks, where this issue wasn't found. Also, those mocks didn't validate that the correct parameters were provided, so that's fixed now. The root cause was the PrepareResetStreams was only called if there wasn't an ongoing stream reset operation in progress. One may try to solve it by always calling PrepareResetStreams also when there is an ongoing request, or to call it when the request has finished. One would then realize that when the response of the outgoing stream request is received, and CommitResetStreams is called, it would reset all paused and (prepared) to-be-reset streams - not just the ones in the outgoing stream request. One cause of this was the lack of a single source of truth of the stream states. The SendQueue kept track of which streams that were paused, but the stream reset handler kept track of which streams that were resetting. As that's error prone, this CL moves the source of truth completely to the SendQueue and defining explicit stream pause states. A stream can be in one of these possible states: * Not paused. This is the default for an active stream. * Pending to be paused. This is when it's about to be reset, but there is a message that has been partly sent, with fragments remaining to be sent before it can be paused. * Paused, with no partly sent message. In this state, it's ready to be reset. * Resetting. A stream transitions into this state when it has been paused and has been included in an outgoing stream reset request. When this request has been responded to, the stream can really be reset (SSN=0, MID=0). This CL also improves logging, and adds socket tests to catch this issue. Bug: webrtc:13994, chromium:1320194 Change-Id: I883570d1f277bc01e52b1afad62d6be2aca930a2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261180 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36771}
2022-05-02 17:15:57 +02:00
EXPECT_CALL(producer_, HasStreamsReadyToBeReset()).WillOnce(Return(true));
EXPECT_CALL(producer_, GetStreamsReadyToBeReset())
.WillOnce(Return(std::vector<StreamID>({StreamID(43)})));
dssctp: support socket handover in StreamResetHandler Bug: webrtc:13154 Change-Id: Idafbed4f3c1af8d0cca833ba983c4b4b99118335 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232121 Reviewed-by: Victor Boivie <boivie@webrtc.org> Commit-Queue: Sergey Sukhanov <sergeysu@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35012}
2021-09-16 07:27:47 +02:00
ASSERT_HAS_VALUE_AND_ASSIGN(ReConfigChunk reconfig,
handler_->MakeStreamResetRequest());
ASSERT_HAS_VALUE_AND_ASSIGN(
OutgoingSSNResetRequestParameter req,
reconfig.parameters().get<OutgoingSSNResetRequestParameter>());
EXPECT_EQ(req.request_sequence_number(),
ReconfigRequestSN(kMyInitialReqSn.value() + 1));
EXPECT_EQ(req.sender_last_assigned_tsn(),
TSN(*retransmission_queue_->next_tsn() - 1));
EXPECT_THAT(req.stream_ids(), UnorderedElementsAre(StreamID(43)));
}
}
dcsctp: Handle in-progress stream sequence numbers When an outgoing stream reset is sent, with sequence number A, and the receiver can't perform it immediately, it will return IN_PROGRESS with response sequence number A. This is then retried with sequence number A+1, and the peer would then possibly respond PERFORMED with response sequence number A+1. Before this CL, whenever a request was sent that didn't immediately succeed, it wouldn't increment its expected response sequence number. So in the retry above, the socket would still expect the response sequence number to stay at A, not at A+1. Bug: webrtc:13994 Change-Id: I6f36d45229a7fb312e97ad15826e0377f4efb64f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261310 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36797}
2022-05-06 12:32:01 +02:00
TEST_F(StreamResetHandlerTest, PerformCloseAfterOneFirstFailing) {
// Inject a stream reset on the first expected TSN (which hasn't been seen).
Parameters::Builder builder;
builder.Add(OutgoingSSNResetRequestParameter(
kPeerInitialReqSn, ReconfigRequestSN(3), kPeerInitialTsn, {StreamID(1)}));
// The socket is expected to say "in progress" as that TSN hasn't been seen.
std::vector<ReconfigurationResponseParameter> responses =
HandleAndCatchResponse(ReConfigChunk(builder.Build()));
EXPECT_THAT(responses, SizeIs(1));
EXPECT_EQ(responses[0].result(), ResponseResult::kInProgress);
// Let the socket receive the TSN.
DataGeneratorOptions opts;
opts.message_id = MID(0);
reasm_->Add(kPeerInitialTsn, gen_.Ordered({1, 2, 3, 4}, "BE", opts));
reasm_->MaybeResetStreamsDeferred(kPeerInitialTsn);
data_tracker_->Observe(kPeerInitialTsn);
// And emulate that time has passed, and the peer retries the stream reset,
// but now with an incremented request sequence number.
Parameters::Builder builder2;
builder2.Add(OutgoingSSNResetRequestParameter(
ReconfigRequestSN(*kPeerInitialReqSn + 1), ReconfigRequestSN(3),
kPeerInitialTsn, {StreamID(1)}));
// This is supposed to be handled well.
std::vector<ReconfigurationResponseParameter> responses2 =
HandleAndCatchResponse(ReConfigChunk(builder2.Build()));
EXPECT_THAT(responses2, SizeIs(1));
EXPECT_EQ(responses2[0].result(), ResponseResult::kSuccessPerformed);
}
dcsctp: Add Stream Reset Handler The Stream Reset handler handles a limited subset of RFC6525, but all the parts necessary to implement "Closing a Data Channel", which is done by sending an Outgoing SSN Reset Request. There can only be a single "Stream Reconfiguration Request" on the wire at any time, so requests are queued and sent when a previous request - if any - finishes. Resetting a stream is an asynchronous operation and the receiver will not perform the stream resetting until it can be done, which is when the currently partly received message has been fully received. And the sender will not send a request until the currently fragmented message (on that stream) is still sent. There are numerous callbacks to make the client know what's really happening as these callbacks will result in Data Channel events. Bug: webrtc:12614 Change-Id: I9fd0a94713f0c1fc384d1189f3894e87687408b7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214131 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33856}
2021-04-06 20:47:11 +02:00
} // namespace
} // namespace dcsctp
Reference in New Issue Copy Permalink