The socket fuzzer is build as a structure-aware fuzzer where the full
public API is exercised as well as receival of SCTP packets with random
sequences of valid chunks.
It begins by putting the socket in a defined starting state and then,
based on the fuzzing data, performs a sequence of operations on the
socket such as receiving packets, sending data, resetting streams or
expiring timers.
This is the first iteration, and when running it a while and analyzing
code coverage, it will be modified to perform better. It could probably
be a little more random.
Bug: webrtc:12614
Change-Id: I50d6ffaecef5722be5cf666fee2f0de7d15cc2e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218500
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33998}
It's responsible for answering incoming Heartbeat Requests, and to
send requests itself when a connection is idle. When it receives
a response, it will measure the RTT and if it doesn't receive a response
in time, that will result in a TX error, which will eventually close
the connection.
Bug: webrtc:12614
Change-Id: I08371d9072ff0461f60e0a2f7696c0fd7ccb57c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214129
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33828}
When the client asks for a message to be sent, it's put in the
SendQueue, which is available even when the socket is not yet connected.
When the socket is connected, those messages will be sent on the wire,
possibly fragmented if the message is large enough to not fit inside a
single packet. When the message has been fully sent, it's removed from
the send queue (but it will be in the RetransmissionQueue - which is
added in a follow-up change, until the message has been ACKed).
The Send Queue is a FIFO queue in this iteration, and in SCTP, that's
called a "First Come, First Served" queue, or FCFS. In follow-up work,
the queue and the actual scheduling algorithm which decides which
message that is sent, when there are messages in multiple streams, will
likely be decoupled. But in this iteration, they're in the same class.
Bug: webrtc:12614
Change-Id: Iec1183e625499a21e402e4f2a5ebcf989bc5c3ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214044
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33798}
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}
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}
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}
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}
