Hi Chris, In the slides from last week's lecture, we should be recalculating the checksum for the acknowledgement before sending it, though this wasn't in the C code: [CITS3002]⬈ ...though I suppose checking the checksum from the acknowledgement isn't included on the previous slide's code either so I understand if the code has just omitted this for simplicity. I'm assuming that we should recalculate & reassign after setting the acknowledgement? Let me know your thoughts, Henry

"Henry Hewgill" <23*1*7*8@s*u*e*t*u*a*e*u*a*> wrote: Hi Henry, Yes, you're correct - in practice, we should be calculating and verifying checksums for everything that could be corrupted (by the Physical Layer), so it applies for both data frames and acknowledgment frames. Those early slides trying to introduce concepts one at a time, so at the bottom of page 6 [CITS3002]⬈ the checksum should be calculated and checked before breaking from the inner loop. However, at that stage we have a problem, because we haven't yet introduced time into our protocols (using timers), so what should we do if the checksum of an arriving DLL_ACK or DLL_NACK frame is wrong? The sender has no concept of time, yet, and thus has no 'pathway' to retransmission of the original data. Moreover, if the receiver had correctly received the original data, it couldn't detect a duplicate retransmission because we haven't yet introduced sequence-numbers. Much of this is corrected by page 20 [CITS3002]⬈ where all frame types are checksummed, we have sequence-numbers, and timers to support retransmission. (but well picked up!)

Hi Chris, Thanks for the reply, yep that's what I was thinking. :) I haven't gotten to duplicate retransmissions yet (though was thinking about it, maybe we store checksums and check against multiple matches? Maybe that's naive...). Timing makes sense, I can see how we: 1. start timer whenever sending 2. stop timer whenever receiving 3. resend & restart timer when negative acknowledgement / junk received 4. resend & restart timer whenever timer runs out 5. success = acknowledgement received (timer already stopped, tell network layer to proceed)

"Henry Hewgill" <23*1*7*8@s*u*e*t*u*a*e*u*a*> wrote: No, no need to store multiple checksums anywhere. We can always recalculate a checksum at any time required. We detect duplicates through the use of sequence-numbers. One advantage to using simulation is that you can 'exhaustively' check your protocols, as opposed to formally proving that they work. Each node in your protocol can only be in a finite (small) number of different states, and the randomness that is introduced means that your protocol will be forced to eventually visit each of those states. Rather than waiting for your protocol to visit all the states, which may take ages, your can run cnet with cnet -F ... and it will advance time as quickly as possible. If it runs successfully for, say, a minute it doesn't *prove* that it's correct, just fairly robust. However, if there is a bug in your protocol, and your check for problems, it's almost guaranteed to find the bug.

Oh nice, so it's effectively a way to force cnet to zoom through all states, thus inducing any errors asap. Will keep it in mind, ty. :)

"Henry Hewgill" <23*1*7*8@s*u*e*t*u*a*e*u*a*> wrote: Sort-of. It doesn't cause the errors, or bad design decisions, to surface, but if they're likely to surface 'sooner-or-later' it makes 'sooner-or-later' arrive sooner.