Adding fuzzers to the build made "gn gen --check" discover a lot
of dependency errors between various components of dcSCTP.
Bug: webrtc:12614
Change-Id: I0b2dd7321aec2624da417f413c727bd11b4743e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215003
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33705}
When migrating to use StrongAlias types, the PPID was incorrectly
modeled as an uint16_t instead of a uint32_t, as it was prior to using
StrongAlias. Most likely a copy-paste error from StreamID.
As the Data Channel PPIDs are in the range of 51-57, it was never caught
in tests.
Bug: webrtc:12614
Change-Id: I2b61ef7935df1222068e7f4e70fc2aaa532dcf7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214960
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33687}
The Reassembly Queue receives fragmented messages (DATA or I-DATA
chunks) and - with help of stream reassemblers - will reassemble these
fragments into messages, which will be delivered to the client.
It also handle partial reliability (FORWARD-TSN) and stream resetting.
To avoid a DoS attack vector, where a sender can send fragments in a way
that the reassembly queue will never succeed to reassemble a message and
use all available memory, the ReassemblyQueue has a maximum size.
Bug: webrtc:12614
Change-Id: Ibb084fecd240d4c414e096579244f8f5ee46914e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214043
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33678}
This class handles the assembly of fragmented received messages (as DATA
chunks) and manage per-stream queues. This class only handles
non-interleaved messages as described in RFC4960, and is not used when
message interleaving is enabled on the association, as described in
RFC8260.
This is also only part of the reassembly - a follow-up change will add
the ReassemblyQueue that handle the other part as well. And an even
further follow-up change will add a "interleaved reassembly stream".
Bug: webrtc:12614
Change-Id: Iaf339fa215a2b14926f5cb74f15528392e273f99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214042
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33677}
The Data Tracker's purpose is to keep track of all received DATA chunks
and to ACK/NACK that data, by generating SACK chunks reflecting its view
of what has been received and what has been lost.
It also contains logic for _when_ to send the SACKs, as that's different
depending on e.g. packet loss. Generally, SACKs are sent every second
packet on a connection with no packet loss, and can also be sent on a
delayed timer.
In case partial reliability is used, and the transmitter has decided
that some data shouldn't be retransmitted, it will send a FORWARD-TSN
chunk, which this class also handles, by "forgetting" about those
chunks.
Bug: webrtc:12614
Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33676}
The Data Generator is a testonly library for generating
Data with correct sequence numbers.
Bug: webrtc:12614
Change-Id: Ifc04dfd14d858d905312ffed13e8905c23d59923
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214041
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@{#33667}
Timer is a high-level timer (in contrast to the low-level `Timeout`
class). Timers are started and can be stopped or restarted. When a timer
expires, the provided callback will be triggered.
Timers can be configured to do e.g. exponential backoff when they expire
and how many times they should be automatically restarted.
Bug: webrtc:12614
Change-Id: Id5eddd58dd0af62184b10dd1f98e3e886e3f1d50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213350
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33666}
The length field was validated to not be too big, or to have too much
padding, but it could be smaller than the fixed size of the chunk, which
isn't correct. Now it's enforced to be at minimum the size of the fixed
size header.
Bug: webrtc:12614
Change-Id: I57089a5ba2854eeb63ab3b4e28cf5878087d06e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214484
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33659}
Every chunk should be at least 4 bytes to be valid - that's the size of
the chunk header. If the embedded length was zero (0), iterating over
the chunks would never complete. Fixed now.
Bug: webrtc:12614
Change-Id: I1cbd070ad34a51584f6b09c5364c3db1b2bcdc2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214483
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33658}
As this library will only use StrongAlias types for all its
sequence numbers, the UnwrappedSequenceNumber class should use those
types and not the primitive underlying types (e.g. uint32_t).
This makes e.g. Unwrap() return a strong type, which is preferred.
Bug: webrtc:12614
Change-Id: Icd0900c643a1988d1a3bbf49d87b4d4d1bbfbf1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213663
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@{#33651}
This represents the wire encoding/decoding of SCTP packets.
Bug: webrtc:12614
Change-Id: Id7a4e4654f29eea126ea3058333f5c625606446b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213349
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33650}
Clients will use this API for all their interactions with this library.
It's made into an interface (of which there will only be a single
implementation) simply for documentation purposes. But that also allows
clients to mock the library if wanted or to have a thread-safe wrapper,
as the library itself is not thread-safe, while keeping the same
interface.
Bug: webrtc:12614
Change-Id: I346af9916e26487da040c01825c2547aa7a5d0b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213348
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33648}
Quite a large commit, but mostly trivial. It adds all the (in dcSCTP)
supported parameters, error causes and chunks as an object model, with
serializers and deserializers. They are verified with packet captures
where available, that have been captured with Wireshark against a
reference implementation.
This _could_ be split in parameter/ as one commit, error_cause/ in the
following, and chunk/ as the third, but as each chunk/parameter is
completely isolated from the other, reviewing it should be linear with
the number of chunks/parameters and having them in more commits wouldn't
change that, taken all those three commits into account.
Bug: webrtc:12614
Change-Id: Ie83c9a22cae6e3a39e35ef26fd532837a6387a08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213347
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33625}
There are numerous identifiers and sequences in SCTP, all of them being
unsigned 16 or 32-bit integers.
* Stream identifiers
* Payload Protocol Identifier (PPID)
* Stream Sequence Numbers (SSN)
* Message Identifiers (MID)
* Fragment Sequence Numbers (FSN)
* Transmission Sequence Numbers (TSN)
The first two of these are publicly exposed in the API, and the
remaining ones are never exposed to the client and are all part of SCTP
protocol.
Then there are some more not as common sequence numbers, and some
booleans. Not all will be in internal_types.h - it depends on if they
can be scoped to a specific component instead. And not all types will
likely become strong types.
The unwrapped sequence numbers have been renamed to not cause conflicts
and the current UnwrappedSequenceNumber class doesn't support wrapping
strongly typed integers as it can't reach into the type of the
underlying integer. That's something to explore later.
Bug: webrtc:12614
Change-Id: I4e0016be26d5d4826783d6e0962044f56cbfa97d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213422
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33620}
These are quite generic utilities that are used by multiple modules
within dcSCTP. Some would be good to have in rtc_base and are simple
replicas of utilities available in abseil.
Bug: webrtc:12614
Change-Id: I9914286ced7317a34628a71697da9149d6d19d38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213190
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33609}
Represents data that is either received and extracted from a
DATA/I-DATA chunk, or data that is supposed to be sent, and
wrapped in a DATA/I-DATA chunk (depending on peer capabilities).
Bug: webrtc:12614
Change-Id: Iea831fa7ca939783a438f178740508e484920312
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213346
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33608}
This is the first and last macro that will go into this project,
but it's really useful to verify that a call returns an optional
value (that is non-nullopt) and that extracts the underlying type.
Bug: webrtc:12614
Change-Id: I0a05bf22466a575dbcc9a8f7b88dde0f55ff54d9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213345
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33607}
Implemented from RFC4960 with test vectors from RFC3720.
Bug: webrtc:12614
Change-Id: If03a41d1ac4acecc3e5840c015878df271b14a1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213344
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33606}
Packets, chunks, parameters and error causes - the SCTP entities
that are sent on the wire - are buffers with fields that are stored
in big endian and that generally consist of a fixed header size, and
a variable sized part, that can e.g. be encoded sub-fields or
serialized strings.
The BoundedByteReader and BoundedByteWriter utilities make it easy
to read those fields with as much aid from the compiler as possible,
by having compile-time assertions that fields are not accessed
outside the buffer's span.
There are some byte reading functionality already in modules/rtp_rtcp,
but that module would be a bit unfortunate to depend on, and doesn't
have the compile time bounds checking that is the biggest feature of
this abstraction of an rtc::ArrayView.
Bug: webrtc:12614
Change-Id: I9fc641aff22221018dda9add4e2c44853c0f64f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212967
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33597}
