HW5 Transport Protocol FSA

Notes:

• This FSA looks more complicated than TCP, but that's only because it includes a lot more detail about how the underlying implementation works than the standard TCP diagram. In essence, I've tried to take rules that are enforced by program variables and code in TCP and put them into the FSA here, where they can be clearly seen. Prominently, the picture shows all message types, interface calls, and events (timeouts) allowed in each state.

• In the skeleton implementation, if a message arrives whose type has no transition out of the current state, it is ignored. (This indicates that at least one side of the conversation is confused, of course, and we expect the protocol will eventually fail, but we don't try to make it fail right now. We should -- the application should be notified as soon as possible, before it has written incorrect data to disk, say -- but we opt for simple and small instead.)

• The skeleton code causes close() invocations to block until all previously sent packets have been "resolved" -- either an ACK has come back or the protocol has given up trying to send them. Implementing that comes fairly directly from the FSA.

• You might wonder about the other side of the coin -- what keeps a received CLOSE packet from transitioning the FSA into a state where receive() isn't allowed before the the application has managed to read all the packets sent to it? The answer is that no state transition takes place at the instant the CLOSE packet is received. Instead, that packet is put into the received packet queue. When (and if) the application performs enough receive()'s to uncover it, the FSA transition then takes place.

• It is typical for SendFile to stop executing while in state PARTNER_CLOSE_WAIT. That happens because the close() call returns to the application once the ACK has been received, and the application terminates. This leaves the other side hanging a bit -- it would like to get an ACK back for its own CLOSE. This problem could be addressed in a number of ways, but the implementation addresses it by not getting very upset if a CLOSE packet isn't ACK'd.

• Most of what you have to do doesn't affect this graph (meaning that this graph doesn't show the details of when packets are sent, for instance), and this graph doesn't affect it.