Hi Chris, I used a different approach than you did to solve the issue of working NACKs into the stop & wait protocol, and I'm wondering if it's equally valid (it certainly works, though might not scale in context of later content?). Instead of testing if you're an outstanding (unacknowledged) sender by checking if 'nextdatatosend != ackexpected' I'm testing if 'lasttimer != NULLTIMER', and updating 'lasttimer = NULLTIMER' when I stop it after receiving a valid acknowledgement. I wanted to get your thoughts on testing against the timers for this, it seems like an equivalent solution, though to see if it's a bad approach for any reason (like upcoming protocol features / considerations). Let me know your thoughts, Henry

"Henry Hewgill" <23*1*7*8@s*u*e*t*u*a*e*u*a*> wrote: Yes, such approaches work as well - you're using the fact that a timer is still 'running' as a Boolean value, which is the same as checking the equivalence of two integer values. However, as those integer values have a *value* that reflects how future frames should be numbered, you'll need to also keep updating it. Don't forget to set the value of your timer to NULLTIMER, both when the ack arrives AND when/if the timer times-out.

Yep makes sense, thanks for the reply. Only thing I wasn't doing was setting the timer to NULLTIMER when it timed out because it immediately sends the data frame again (which restarts the timer). I assumed that setting it to NULLTIMER in-between wouldn't make a difference so I omitted it.

"Henry Hewgill" <23*1*7*8@s*u*e*t*u*a*e*u*a*> wrote: You are correct; it's the sort of thing I often do in my coding 'just in case', so it's not forgotten. It's termed defensive programming. Other examples include adding {...} around code blocks, even if they're only a single line, and the pairing free(pointer); pointer = NULL;