History log of /webrtc/sctp/src/queue/pending_queue.rs (Results 1 – 5 of 5)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: constraints-v0.1.0
# 6bc4a8f1 05-Jan-2023 Anton <[email protected]>

sctp: remove unnecessary drops and use precise padding (#381)

* add comments for QUEUE_BYTES_LIMIT and QUEUE_APPEND_LARGE

* remove unnecessary drop(sem_lock)

lock will be dropped automatically

sctp: remove unnecessary drops and use precise padding (#381)

* add comments for QUEUE_BYTES_LIMIT and QUEUE_APPEND_LARGE

* remove unnecessary drop(sem_lock)

lock will be dropped automatically

* use PADDING_MULTIPLE instead of 16

contract: padding_needed <= PADDING_MULTIPLE

Refs https://github.com/webrtc-rs/webrtc/pull/364 and https://github.com/webrtc-rs/webrtc/pull/367

show more ...


# daaf05d1 02-Jan-2023 Moritz Borcherding <[email protected]>

sctp: limit the bytes in the PendingQueue by using a semaphore (#367)

As discussed in #360 the pending queue can grow indefinitely if the sender writes packets faster than the association is able to

sctp: limit the bytes in the PendingQueue by using a semaphore (#367)

As discussed in #360 the pending queue can grow indefinitely if the sender writes packets faster than the association is able to transmit them.

This PR solves this by enforcing a limit on the pending queue. This blocks the sender until enough space is free.

show more ...


Revision tags: interceptor-v0.8.2, rtcp-v0.7.2, mdns-v0.5.2, v0.6.0, interceptor-v0.8.1, media-v0.5.0, data-v0.6.0, sctp-v0.7.0, srtp-v0.9.1, rtcp-v0.7.1, rtp-v0.6.8, dtls-v0.7.0, ice-v0.9.0, turn-v0.6.1, stun-v0.4.4, mdns-v0.5.1, sdp-v0.5.3, util-v0.7.0
# 0acb5a49 15-Nov-2022 Anton Kaliaev <[email protected]>

[sctp] make `write` sync (#344)

There's no reason for it to be async because it just buffers the data in memory (actual IO is happening in a separate thread).


# 4b638fa6 10-Nov-2022 Anton Kaliaev <[email protected]>

add `PendingQueue::append` (#345)

which appends chunks to the back of the pending queue.

Consider the following two simultaneous calls to `send_payload_data`:

```
1. [beginning_fragment1, d

add `PendingQueue::append` (#345)

which appends chunks to the back of the pending queue.

Consider the following two simultaneous calls to `send_payload_data`:

```
1. [beginning_fragment1, data2, data3, ending_fragment4]
2. [beginning_fragment5, data6, data7, ending_fragment8]
```

If `push` is used, due to individual locks, it's possible to end up with:

```
[beginning_fragment1, data2, beginning_fragment5, data3, data6, ending_fragment4,
data6, data7, ending_fragment8]
```

This will result in wrong data received by the remote.

show more ...


Revision tags: ice-v0.8.2, v0.5.1, ice-v0.8.1, v0.5.0, data-v0.5.0, dtls-v0.6.0, ice-v0.8.0, interceptor-v0.8.0, mdns-v0.5.0, media-v0.4.7, rtcp-v0.7.0, rtp-v0.6.7, sctp-v0.6.1, sdp-v0.5.2, srtp-v0.9.0, stun-v0.4.3, turn-v0.6.0, util-v0.6.0, test-tag
# ffe74184 23-Aug-2022 Martin Algesten <[email protected]>

Move all to top level