Commit graph

3 commits

Author SHA1 Message Date
Artem Titov
c374d11fac Move to_queued_task.h and pending_task_safety_flag.h into public API
Bug: b/235812579
Change-Id: I9fa3dc4a65044df8b44fff4e9bfeac7233fa381c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266080
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37248}
2022-06-17 09:20:39 +00:00
Henrik Boström
b951dc6f4c 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:40:24 +00:00
Victor Boivie
de88b08b94 dcsctp: Add TaskQueue based timeout implementation
This is about doing the best with what we have. As delayed tasks can't
be cancelled, and dcSCTP timers will almost always be stopped or
restarted, and will generally only expire on packet loss.

This implementation will post a delayed task whenever a Timeout is
started. Whenever it's stopped or restarted, it will keep the scheduled
delay task running (there's no alternative), but it will also not start
a new delayed task on subsequent starts/restarts. Instead, it will wait
until the original delayed task has triggered, and will then - if the
timer is still running, which it probably isn't - post a new delayed
task with the remainder of the the duration.

There is special handling for when a shorter duration is requested, as
that can't re-use the scheduled task, but that shouldn't be very common.

Bug: webrtc:12614
Change-Id: I7f3269cabf84f80dae3b8a528243414a93d50fc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217223
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33904}
2021-05-03 16:12:30 +00:00