If the teacher issues a "reset" it should automatically log out any logged in Student Web clients, not leave them logged in.

[truedat101]

These creates a bad situation that a teacher may encounter, whereby they've logged in, started a session, and then decide to restart for some reason, and leave all the clients logged in and "stranded" as the server no longer contains their data.

[truedat101]

We need a new message type:

{ TYPE: 'RESET'}

The benefit will be that as clients see a reset type message, they either ignore it if they can't handle, or actually do a reset. As soon as the teacher is ready, they can start a session.

[truedat101]

One problem, if we stick a RESET in the queue, it will stay there until the teacher logs in. We either need for the teacher to log back in and remove the RESET message, or simply pass along { TYPE: 'RESET' , TIMESTAMP: "SOME DATE"}, and then it would be up to clients to observe or ignore the RESET. It's sort of tricky. Once you've seen a reset, and logged in, you want to just ignore it. If you are logging in for the first time, then perhaps this is a big annoyance, as you'd get re-logged out the first time you see the reset. If the login date was newer than the reset timestamp, then you could ignore the reset.

[truedat101]

In my old EpochEDU designs, I sent individual messages to each client, sort of 1-M broadcast, and then I'd remove the message from that client's queue. If the messages were not seen, they would store in a FIFO queue until processed. Would this would lead to was a backlog, such that the student web app would see these and process all of them, which had a negative consequence for anyone joining a session late. On the one hand, you wanted to receive all chat messages, but not all control messages.

So, maybe then what we need is: { TYPE: 'RESET' , TIMESTAMP: "SOME DATE", EXPIRY: "SOME TIMEOUT IN MS" }

So a client would login, observe the current message, see a RESET, and then check the timestamp. If the current time is older than TIMESTAMP + EXPIRY, then ignore the message, otherwise, it is possible the RESET was issued in or around the time the user was logging in, in which case we really need the user to log back out.

[truedat101]

Only problem ... if our time clocks are not in agreement, this doesn't work. If the android device had its clock set in past or future, we'd have some strange behavior.

[truedat101]

We could have the client observe the first sighting of a reset, store the timestamp of the observed reset (stored in the message), and if it is seen again, ignore it.

[truedat101]

For simplicity, since this is a non-core issue, we just want to do this in the server, just long enough to trigger all clients to reset, and then have them log out. So server will set the message, and within 1 second, remove it.

[truedat101]

Ok, so we want to set it to 2 seconds, as 1 second may be too short. In reality we need to store and forward these messages with an expiration, but for now don't worry about it. It seems to work well as it stands and the client STATEMACHINE needed cleanup since we try to do proper restore login state and set state to 1.