Subject: assn6 race conditions and assn5 woes

(This message is being sent to all CPSC 360 students)

When running with sender and receiver on the same system
a protocol failure can be triggered in rps_sender() by
doing:

   write(...)
   rpsock->nxtsnd = rps_increment(rpsock->nxtsnd);

which, alas is just how I had it in the notes :-(
(but not in my version of the program so I didn't notice
the problem)

------------

The problem (thanks to excellent detective work by Mr. Shay)
occurs when the sender program is prempted after the write()
but before the increment AND then the receiver program
consumes the packet and generates an ACK, AND then the
rps_rcvack() back in the sender program processes the ACK
STILL BEFORE rpsock->nxtsnd has been incremented.


The problem can be defeated by simply reversing the order:

   rpsock->nxtsnd = rps_increment(rpsock->nxtsnd);
   write(...)


-------------------

For those of you who are still struggling with assn3 and assn5
you can minimize your time if you will simply follow the
following friendly advice.

I believe in 100% of the cases in which struggling students
have come to my office, I have been a able to bring up a
a copy of one or more of their functions along side a copy
of the pseudocode from the notes and say where in your
function do you "invoke ring_add_slot()" or "increment nxtsnd"
or some such.  The inevitable response is NEVER "I thought
this code did that".  It is ALWAYS well I guess I forgot to
put that in.

This project is sufficiently hard that haphazard approaches
to writing it can indeed make it virtually impossible.  I
recommend a "checklist" approach in which you PRINT the notes
and put a check by each bullet in the psuedocode AFTER you
have implemented it in your program.

Your program still may not work. I understand that and will be
pleased to help you fix it. But we can reach that objective SO
much more efficiently if you will take the time to ensure that
the program is not simply MISSING necessary elements that are
spelled out in the notes.