This avoids copying the payload at all. Future CL will change the
transport.
In performance tests, memcpy was visible in the performance profiles
prior to this change.
Bug: webrtc:12943
Change-Id: I507a1a316165db748e73cf0d58c1be62cc76a2d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236346
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35428}
It's useful for other parts of WebRTC and there is no real reason why
it should be located in net/dcsctp.
Bug: None
Change-Id: Iccaed4e943e21ddaea8603182d693114b2da9f6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232606
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35055}
The Retransmission Queue contain all message fragments (DATA chunks)
that have once been sent, but not yet ACKed by the receiver. It will
process incoming SACK chunks, which informs it which chunks that the
receiver has seen (ACKed) and which that are lost (NACKed), and will
retransmit chunks when it's time.
If a message has been sent with partial reliability, e.g. to have a
limited number of retransmissions or a limited lifetime, the
Retransmission Queue may discard a partially sent and expired message
and will instruct the receiver that "don't expect this message - it's
expired" by sending a FORWARD-TSN chunk.
This currently also includes the congestion control algorithm as it's
tightly coupled with the state of the retransmission queue. This is
a fairly complicated piece of logic which decides how much data that
can be in-flight, depending on the available bandwidth. This is not done
by any bandwidth estimation, but similar to TCP, where data is sent
until it's lost, and then "we dial down a knob" and take it more
carefully from here on.
Future refactoring will try to separate the logic regarding fragment
retransmission and the congestion control algorithm.
Bug: webrtc:12614
Change-Id: I8678250abb766e567c3450634686919936ea077b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214046
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33833}
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}
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}
