Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receiver decoding process stuck in an infinite loop #3

Open
pkuzmin opened this issue Jul 12, 2023 · 1 comment
Open

Receiver decoding process stuck in an infinite loop #3

pkuzmin opened this issue Jul 12, 2023 · 1 comment

Comments

@pkuzmin
Copy link

pkuzmin commented Jul 12, 2023

When transferring files, if there is a loss of UDP packets and the reblock process cannot assemble a block for decoding, such a loss of synchronization may occur, in which, as a result, the decoding process gets stuck in an infinite loop (the condition *to_receive == block_id is not met)

loop {
let mut to_receive = receiver.block_to_receive.lock().expect("acquire lock");
if *to_receive == block_id {
receiver
.to_dispatch
.send(protocol::Message::deserialize(block))?;
*to_receive = to_receive.wrapping_add(1);
break;
}
}

Packet loss can be simulated with such a simple code

diff --git a/src/receive/reblock.rs b/src/receive/reblock.rs
index 1e44c5b..8b08564 100644
--- a/src/receive/reblock.rs
+++ b/src/receive/reblock.rs
@@ -15,6 +15,7 @@ pub(crate) fn start<F>(receiver: &receive::Receiver<F>) -> Result<(), receive::E
     let mut prev_queue: Option<Vec<raptorq::EncodingPacket>> = None;
     let mut queue = Vec::with_capacity(capacity);
     let mut block_id = 0;
+    let mut pktcnt = 0;

     loop {
         let packets = match receiver
@@ -49,6 +50,14 @@ pub(crate) fn start<F>(receiver: &receive::Receiver<F>) -> Result<(), receive::E
         };

         for packet in packets {
+            // simple simulation of packet loss
+            pktcnt += 1;
+            if pktcnt > (353 + 44) {
+                pktcnt = 0;
+            }
+            else if pktcnt > 353 {
+                continue;
+            }
             let payload_id = packet.payload_id();
             let message_block_id = payload_id.source_block_number();

BR,
Pavel

github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 10, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 11, 2024
github-af added a commit to github-af/lidi that referenced this issue Jul 11, 2024
r3dlight pushed a commit that referenced this issue Jul 29, 2024
* revert cccecec

* fix issue #3

* refactor decode/dispatch for new reordering thread
@r3dlight r3dlight mentioned this issue Jul 29, 2024
@github-af
Copy link
Contributor

@pkuzmin The reblock process has been reviewed: there is a new reordering process now in charge of dealing with the ordering of received blocks. This process cannot be stuck in an infinite loop; in case of synchronization lost, the error is propagated; It should also solve the issue #4.

r3dlight pushed a commit that referenced this issue Jul 29, 2024
* revert cccecec

* fix issue #3

* refactor decode/dispatch for new reordering thread
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants