admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
webrtc_m130/net/dcsctp/socket/BUILD.gn

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

141 lines
3.2 KiB
Plaintext
Raw Normal View History

dcsctp: Add Context 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}
2021-04-06 16:39:39 +02:00
# Copyright (c) 2021 The WebRTC project authors. All Rights Reserved.
#
# Use of this source code is governed by a BSD-style license
# that can be found in the LICENSE file in the root of the source
# tree. An additional intellectual property rights grant can be found
# in the file PATENTS. All contributing project authors may
# be found in the AUTHORS file in the root of the source tree.
import("../../../webrtc.gni")
rtc_source_set("context") {
sources = [ "context.h" ]
deps = [
"../common:internal_types",
"../packet:sctp_packet",
"../public:socket",
"../public:types",
]
}
dcsctp: Add Heartbeat Handler 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}
2021-04-06 19:55:51 +02:00
rtc_library("heartbeat_handler") {
deps = [
":context",
"../../../api:array_view",
"../../../rtc_base",
"../../../rtc_base:checks",
"../../../rtc_base:rtc_base_approved",
"../public:types",
]
sources = [
"heartbeat_handler.cc",
"heartbeat_handler.h",
]
}
dcsctp: Add Stream Reset Handler 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}
2021-04-06 20:47:11 +02:00
rtc_library("stream_reset_handler") {
deps = [
":context",
"../../../api:array_view",
"../../../rtc_base",
"../../../rtc_base:checks",
"../../../rtc_base:rtc_base_approved",
"../public:types",
]
sources = [
"stream_reset_handler.cc",
"stream_reset_handler.h",
]
}
dcsctp: Add Transmission Control Block 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}
2021-04-07 08:57:28 +02:00
rtc_library("transmission_control_block") {
deps = [
":context",
":heartbeat_handler",
":stream_reset_handler",
"../../../api:array_view",
"../../../rtc_base",
"../../../rtc_base:checks",
"../../../rtc_base:rtc_base_approved",
"../common:sequence_numbers",
"../packet:sctp_packet",
"../public:socket",
"../public:types",
"../rx:data_tracker",
"../rx:reassembly_queue",
"../timer:timer",
"../tx:retransmission_error_counter",
"../tx:retransmission_queue",
"../tx:retransmission_timeout",
"../tx:send_queue",
]
sources = [
"capabilities.h",
"transmission_control_block.cc",
"transmission_control_block.h",
]
}
dcsctp: Add Socket This completes the basic implementation of the dcSCTP library. There are a few remaining commits to e.g. add compatibility tests and benchmarks, as well as more support for e.g. RFC8260, but those are not strictly vital for evaluation of the library. The Socket contains the connection establishment and teardown sequences as well as the general chunk dispatcher. Bug: webrtc:12614 Change-Id: I313b6c8f4accc144e3bb88ddba22269ebb8eb3cd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214342 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33890}
2021-04-08 09:56:59 +02:00
rtc_library("dcsctp_socket") {
deps = [
":context",
":transmission_control_block",
"../../../api:array_view",
"../../../rtc_base",
"../../../rtc_base:checks",
"../../../rtc_base:rtc_base_approved",
"../packet:chunk_validators",
"../public:types",
"../tx:fcfs_send_queue",
]
sources = [
"callback_deferrer.h",
"dcsctp_socket.cc",
"dcsctp_socket.h",
"state_cookie.cc",
"state_cookie.h",
]
}
dcsctp: Add Context 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}
2021-04-06 16:39:39 +02:00
if (rtc_include_tests) {
rtc_source_set("mock_callbacks") {
testonly = true
sources = [ "mock_dcsctp_socket_callbacks.h" ]
deps = [ "../public:socket" ]
}
rtc_source_set("mock_context") {
testonly = true
sources = [ "mock_context.h" ]
deps = [
":context",
":mock_callbacks",
"../common:internal_types",
"../packet:sctp_packet",
"../public:socket",
"../public:types",
]
}
dcsctp: Add Heartbeat Handler 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}
2021-04-06 19:55:51 +02:00
rtc_library("dcsctp_socket_unittests") {
testonly = true
deps = [
dcsctp: Add Socket This completes the basic implementation of the dcSCTP library. There are a few remaining commits to e.g. add compatibility tests and benchmarks, as well as more support for e.g. RFC8260, but those are not strictly vital for evaluation of the library. The Socket contains the connection establishment and teardown sequences as well as the general chunk dispatcher. Bug: webrtc:12614 Change-Id: I313b6c8f4accc144e3bb88ddba22269ebb8eb3cd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214342 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33890}
2021-04-08 09:56:59 +02:00
":dcsctp_socket",
dcsctp: Add Heartbeat Handler 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}
2021-04-06 19:55:51 +02:00
":heartbeat_handler",
dcsctp: Add Stream Reset Handler 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}
2021-04-06 20:47:11 +02:00
":stream_reset_handler",
dcsctp: Add Heartbeat Handler 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}
2021-04-06 19:55:51 +02:00
"../../../api:array_view",
"../../../rtc_base:checks",
"../../../rtc_base:gunit_helpers",
"../../../rtc_base:rtc_base_approved",
"../../../test:test_support",
]
dcsctp: Add Stream Reset Handler 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}
2021-04-06 20:47:11 +02:00
sources = [
dcsctp: Add Socket This completes the basic implementation of the dcSCTP library. There are a few remaining commits to e.g. add compatibility tests and benchmarks, as well as more support for e.g. RFC8260, but those are not strictly vital for evaluation of the library. The Socket contains the connection establishment and teardown sequences as well as the general chunk dispatcher. Bug: webrtc:12614 Change-Id: I313b6c8f4accc144e3bb88ddba22269ebb8eb3cd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214342 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33890}
2021-04-08 09:56:59 +02:00
"dcsctp_socket_test.cc",
dcsctp: Add Stream Reset Handler 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}
2021-04-06 20:47:11 +02:00
"heartbeat_handler_test.cc",
dcsctp: Add Socket This completes the basic implementation of the dcSCTP library. There are a few remaining commits to e.g. add compatibility tests and benchmarks, as well as more support for e.g. RFC8260, but those are not strictly vital for evaluation of the library. The Socket contains the connection establishment and teardown sequences as well as the general chunk dispatcher. Bug: webrtc:12614 Change-Id: I313b6c8f4accc144e3bb88ddba22269ebb8eb3cd Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214342 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33890}
2021-04-08 09:56:59 +02:00
"state_cookie_test.cc",
dcsctp: Add Stream Reset Handler 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}
2021-04-06 20:47:11 +02:00
"stream_reset_handler_test.cc",
]
dcsctp: Add Heartbeat Handler 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}
2021-04-06 19:55:51 +02:00
}
dcsctp: Add Context 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}
2021-04-06 16:39:39 +02:00
}
Reference in New Issue Copy Permalink