Receiver decoding process stuck in an infinite loop

[pkuzmin]

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) https://github.com/ANSSI-FR/lidi/blob/3d8654e6ec12aba61001c2dcdad8aecc3479a54b/src/receive/decoding.rs#L30-L39 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]

@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.