0
代码
代码
Issues
Pull Requests
讨论
Wiki
分析
0
WWebRTC LUCI CQdcsctp: Abandon correct message on stream reset
9cf825de创建于 2023年10月6日历史提交
文件最后提交记录最后更新时间
BUILD.gn
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
mock_send_queue.h
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
outstanding_data.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
outstanding_data.h
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
outstanding_data_test.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
retransmission_error_counter.cc
dcsctp: Support unlimited max_retransmissions The restart limit for timers can already be limitless, but the RetransmissionErrorCounter didn't support this. With this change, the max_retransmissions and max_init_retransmits can be absl::nullopt to indicate that there should be infinite retries. Bug: webrtc:13129 Change-Id: Ia6e91cccbc2e1bb77b3fdd7f37436290adc2f483 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230701 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34882} 4 年前
retransmission_error_counter.h
dcsctp: Make use of log_prefix consistent The log_prefix frequently used in dcSCTP is intended to be used to separate logs from different sockets within the same log output, typically in unit tests. Every log entry always has the file and line, so it's not important to add more information to the log prefix that indicates _where_ it's logged. So those have been removed. Also, since log_prefix is a string (typically 32 bytes) and it's never changing during the lifetime of the socket, pass and store it as a absl::string_view to save memory. Bug: None Change-Id: I10466710ca6c2badfcd3adc5630426a90ca74204 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274704 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39571} 3 年前
retransmission_error_counter_test.cc
dcsctp: Support unlimited max_retransmissions The restart limit for timers can already be limitless, but the RetransmissionErrorCounter didn't support this. With this change, the max_retransmissions and max_init_retransmits can be absl::nullopt to indicate that there should be infinite retries. Bug: webrtc:13129 Change-Id: Ia6e91cccbc2e1bb77b3fdd7f37436290adc2f483 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230701 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#34882} 4 年前
retransmission_queue.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
retransmission_queue.h
dcsctp: Don't generate FORWARD-TSN across stream resets This was a fun bug which proved to be challenging to find a good solution for. The issue comes from the combination of partial reliability and stream resetting, which are covered in different RFCs, and where they don't refer to each other... Stream resetting (RFC 6525) is used in WebRTC for closing a Data Channel, and is done by signaling to the receiver that the stream sequence number (SSN) should be set to zero (0) at some time. Partial reliability (RFC 3758) - and expiring messages that will not be retransmitted - is done by signaling that the SSN should be set to a certain value at a certain TSN, as the messages up until the provided SSN are not to be expected to be sent again. As these two functionalities both work by signaling to the receiver what the next expected SSN should be, they need to do it correctly not to overwrite each others' intent. And here was the bug. An example scenario where this caused issues, where we are Z (the receiver), getting packets from the sender (A): 5 A->Z DATA (TSN=30, B, SID=2, SSN=0) 6 Z->A SACK (Ack=30) 7 A->Z DATA (TSN=31, E, SID=2, SSN=0) 8 A->Z RE_CONFIG (REQ=30, TSN=31, SID=2) 9 Z->A RE_CONFIG (RESP=30, Performed) 10 Z->A SACK (Ack=31) 11 A->Z DATA (TSN=32, SID=1) 12 A->Z FORWARD_TSN (TSN=32, SID=2, SSN=0) Let's assume that the path Z->A had packet loss and A never really received our responses (#6, #9, #10) in time. At #5, Z receives a DATA fragment, which it acks, and at #7 the end of that message. The stream is then reset (#8) which it signals that it was performed (#9) and acked (#10), and data on another stream (2) was received (#11). Since A hasn't received any ACKS yet, and those chunks on SID=2 all expired, A sends a FORWARD-TSN saying that "Skip to TSN=32, and don't expect SID=2, SSN=0". That makes the receiver expect the SSN on SID=2 to be SSN=1 next time at TSN=32. But that's not good at all - A reset the stream at #8 and will want to send the next message on SID=2 using SSN=0 - not 1. The FORWARD-TSN clearly can't have a TSN that is beyond the stream reset TSN for that stream. This is just one example - combining stream resetting and partial reliability, together with a lossy network, and different variants of this can occur, which results in the receiver possibly not delivering packets because it expects a different SSN than the one the sender is later using. So this CL adds "breakpoints" to how far a FORWARD-TSN can stretch. It will simply not cross any Stream Reset last assigned TSNs, and only when a receiver has acked that all TSNs up till the Stream Reset last assigned TSN has been received, it will proceed expiring chunks after that. Bug: webrtc:14600 Change-Id: Ibae8c9308f5dfe8d734377d42cce653e69e95731 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321600 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40829} 2 年前
retransmission_queue_test.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
retransmission_timeout.cc
dcsctp: Specify an initial RTT The RTT will quickly be updated whenever a DATA chunk is acked, but the initial value was set to zero. In unit tests, which often are short and rarely increase the simulated time between a DATA is sent, and acked, the smoothed RTT would usually stay at 0, which causes e.g. the rate limiting of FORWARD not to work. Bug: None Change-Id: Ieb515fe875ce88d001777b00d6efd9762565a09d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273900 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38013} 3 年前
retransmission_timeout.h
dcsctp: Specify an initial RTT The RTT will quickly be updated whenever a DATA chunk is acked, but the initial value was set to zero. In unit tests, which often are short and rarely increase the simulated time between a DATA is sent, and acked, the smoothed RTT would usually stay at 0, which causes e.g. the rate limiting of FORWARD not to work. Bug: None Change-Id: Ieb515fe875ce88d001777b00d6efd9762565a09d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273900 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38013} 3 年前
retransmission_timeout_test.cc
dcsctp: Specify an initial RTT The RTT will quickly be updated whenever a DATA chunk is acked, but the initial value was set to zero. In unit tests, which often are short and rarely increase the simulated time between a DATA is sent, and acked, the smoothed RTT would usually stay at 0, which causes e.g. the rate limiting of FORWARD not to work. Bug: None Change-Id: Ieb515fe875ce88d001777b00d6efd9762565a09d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273900 Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38013} 3 年前
rr_send_queue.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
rr_send_queue.h
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
rr_send_queue_test.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
send_queue.h
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前
stream_scheduler.cc
dcsctp: Make use of log_prefix consistent The log_prefix frequently used in dcSCTP is intended to be used to separate logs from different sockets within the same log output, typically in unit tests. Every log entry always has the file and line, so it's not important to add more information to the log prefix that indicates _where_ it's logged. So those have been removed. Also, since log_prefix is a string (typically 32 bytes) and it's never changing during the lifetime of the socket, pass and store it as a absl::string_view to save memory. Bug: None Change-Id: I10466710ca6c2badfcd3adc5630426a90ca74204 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274704 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39571} 3 年前
stream_scheduler.h
dcsctp: Make use of log_prefix consistent The log_prefix frequently used in dcSCTP is intended to be used to separate logs from different sockets within the same log output, typically in unit tests. Every log entry always has the file and line, so it's not important to add more information to the log prefix that indicates _where_ it's logged. So those have been removed. Also, since log_prefix is a string (typically 32 bytes) and it's never changing during the lifetime of the socket, pass and store it as a absl::string_view to save memory. Bug: None Change-Id: I10466710ca6c2badfcd3adc5630426a90ca74204 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274704 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Commit-Position: refs/heads/main@{#39571} 3 年前
stream_scheduler_test.cc
dcsctp: Abandon correct message on stream reset Before this CL, a message was identified by the triple (stream_id, is_unordered, MID) (and yes, the MID is always present in the send queue, even when interleaved message is not enabled.). So when a chunk was abandoned due to e.g. having reached the retransmission limit, all other chunks for that message in the retransmission queue, and all unsent chunks in the send queue were discarded as well. This works well, except for the fact that resetting a stream will result in the MID being set to zero again, which can result in two different messages having the same identifying triple. And due to the implementation, both messages would get abandoned. In WebRTC, an entire data channels is either reliable or unreliable, and for a message to be abandoned, the channel must be unreliable. So this means that in the case of stream resets - meaning that a channel was closed and then reopened, an abandoned message from the old (now closed) channel would result in abandoning another message sent on the re-opened data channel. This CL introduces a new internal property on messages while in the retransmission and send queue; The "outgoing message id". It's a monotonically increasing identifier - shared among all streams - that is never reset to zero in the event of a stream reset. And now a message is actually only identified by the outgoing message id, but often used together with the stream identifier, as all data in the send queue is partitioned by stream. This identifier is 32 bits wide, allowing at most four billion messages to be in-flight, which is not a limitation, as the TSN is also 32 bits wide. Bug: webrtc:14600 Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40881} 2 年前