This is merely a container of components that have their lifetime
bound to when the socket is connected. If the socket gets disconnected
or restarted, this object (and everything it holds) will be released.
Bug: webrtc:12614
Change-Id: Ibd75760b7bf7efe9c26c4eb7cee62de8bba5410c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214340
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33869}
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}
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}
In the Socket module, there are a few (two, to be exact right now, but
the goal is to have even more) separate "handlers" that are responsible
for a feature set. These handlers must have an API to interact with
the rest of the socket - and this is the API.
Mocks are also added.
Bug: webrtc:12614
Change-Id: If19b43bf99a784bba3a42467d0ed3abdd8b4c62c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214128
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@{#33826}