dcsctp: Don't sent more packets before COOKIE ACK

While in the COOKIE ECHO state, there is a TCB and there might be data
in the send buffer, and RFC4960 allows the COOKIE ECHO chunk to bundle
additional DATA chunks in the same packet, but there mustn't be more
than one such packet sent, and that packet must have a COOKIE ECHO chunk
as the first chunk in it.

When the COOKIE ACK chunk has been received, the socket is allowed to
send multiple packets.

Previously, this was state managed by the socket and not the TCB, as
the socket is responsible for moving between the different states. And
when the COOKIE ECHO chunk was sent, the TCB was instructed to only send
a single packet by the socket.

However, if there were retransmissions or anything else that could
result in calling TransmissionControlBlock::SendBufferedChunks, it would
do as instructed and send those, even if the socket was in a state where
that wasn't allowed.

When the peer was dcSCTP, this didn't cause any issues as dcSCTP tries
to be tolerant in what it receives (but strict in what it sends, except
for when there are bugs). When the peer was usrsctp, it would send an
ABORT for each received packet that didn't have a COOKIE ECHO as the
first chunk, and then restart the handshake (sending an INIT). So this
resulted in a longer handshake, but the connection would eventually be
correctly established and any DATA chunks that resulted in the ABORTs
would've been retransmitted.

By making the TCB aware of that particular state, and to make it
responsible for creating the SCTP packet with the COOKIE ECHO chunk
first, and also to only send a single packet when it is in that state,
there will not be any way to bypass this limitation.

Also, while not explicitly mentioned in the RFC, the retransmission
timer will not affect resending any outstanding DATA chunks that were
bundled together with the COOKIE ECHO chunk, as then there would be two
timers that both would drive resending COOKIE ECHO and DATA chunks.

Bug: webrtc:12880
Change-Id: I76f215a03cceab5bafe9f16eb4775f3dc68a6f05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222645
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34329}
5 files changed
tree: dc6e19edd3d897dcd1fdc42d526bad73a204157e
  1. api/
  2. audio/
  3. build_overrides/
  4. call/
  5. common_audio/
  6. common_video/
  7. data/
  8. docs/
  9. examples/
  10. g3doc/
  11. logging/
  12. media/
  13. modules/
  14. net/
  15. p2p/
  16. pc/
  17. resources/
  18. rtc_base/
  19. rtc_tools/
  20. sdk/
  21. stats/
  22. system_wrappers/
  23. test/
  24. tools_webrtc/
  25. video/
  26. .clang-format
  27. .git-blame-ignore-revs
  28. .gitignore
  29. .gn
  30. .vpython
  31. AUTHORS
  32. BUILD.gn
  33. CODE_OF_CONDUCT.md
  34. codereview.settings
  35. DEPS
  36. DIR_METADATA
  37. ENG_REVIEW_OWNERS
  38. g3doc.lua
  39. LICENSE
  40. license_template.txt
  41. native-api.md
  42. OWNERS
  43. PATENTS
  44. PRESUBMIT.py
  45. presubmit_test.py
  46. presubmit_test_mocks.py
  47. pylintrc
  48. README.chromium
  49. README.md
  50. WATCHLISTS
  51. webrtc.gni
  52. webrtc_lib_link_test.cc
  53. whitespace.txt
README.md

WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.

Development

See here for instructions on how to get started developing with the native code.

Authoritative list of directories that contain the native API header files.

More info