0

Let's say the sender and the receiver got a 16 size buffer with a 7 size window.

In other words, each side has a buffer, an array, where they can store 16 frames. Each frame has an id that fits in the 16 frames buffer (index in the array). The receiver got a window that only allow 7 frames in any order to be accepted at any given time. The window will slide by one when it got the oldest frame in the buffer filled.

My problem now is, let's say if a frame get lost on the way, but somehow make it back way too late. The receiver got it so late it actually fills the next circle of the frame's buffer.

  1. The sender send the frames: 0, 1, 2, 3, 4, 5, 6, 7.
  2. The receiver gets the frames and sends an ACK back for having got all up to 7 (or for each one).
  3. The sender gets a timeout on frame 0, and re-sends it.
  4. The sender gets ACK on all up to 7, so it sends the next frames: 8, 9, 10, 11, 12, 13, 14
  5. The receiver gets the following packets: 8, 9, 10, 11, 12, 13, 14. It sends an ACK for having got them and open ups the buffer for: 15, 0, 1, 2, 3, 4, 5, 6.
  6. The receiver gets the old frame 0 that was sent by the sender due to a timeout. The receiver think the packet is legit and stores it.

How to avoid what happened at step 6? Should I send a CRC of the entire window? CRC is not perfect, so there may still be issues.

I'm currently doing this over an UDP socket in C, hence the C tag.

Horse SMith
  • 1,003
  • 2
  • 12
  • 25
  • I'm not following what your application is here - if you're looking for strong ordering, sliding-window reassembly, and retransmission on loss, why not just use TCP? The obvious answer to your question is "include a sequence number", but then that's just another feature of TCP. – Polynomial Mar 09 '14 at 15:24
  • I'm not going to use TCP. I already mentioned I do "id" them, but still I find an issue. Did I do it wrong? EDIT: I went ahead and specified I use selective repeat. – Horse SMith Mar 09 '14 at 15:29
  • When someone says "I want to do [x] without using [y]", and [y] is the standard, industry accepted, pre-built option for doing [x], it usually means they're taking the wrong approach. What rationale do you have for avoiding TCP? What property does TCP have that is sub-optimal for your use-case, to the point where re-implementing *most* of TCP over UDP becomes a good idea? – Polynomial Mar 09 '14 at 15:37
  • 1
    @Polynomial , I'm not going to argue for why I've selected to do it this way, I'm just looking for a solution to the problem I face. I do agree with you though, but I'm doing this to learn how to do it, so using TCP is no good. – Horse SMith Mar 09 '14 at 15:47
  • You can check this answer: [Selective Repeat | Thread Way](http://stackoverflow.com/questions/29073719/go-back-n-vs-selective-repeat/40034443#40034443) – SHA2NK Oct 14 '16 at 03:32

0 Answers0