==VIII.10 (n+1)sec Session Management and Message Handling==
This section explains the rule - based on which - (n+1)sec governs the order when multiple participants try to join or leave a session simultaneously. Every participant in a chat room has either the status of a "joiner" or a "participant" of a confirmed session exclusively. Based on the user status and the message received, a specific subprotocol needs to be run by the user which is explained in the following sections.
If the message has a session id of a session that the user is part of, then message handling is governed by the finite state machine table described below. Otherwise, the messages should be handled as follows:
user_in_room_state == JOINING
* Messages without session id (including JOIN_REQUEST):The Joiner, user in "JOINIG" state will ignores all messages without session id.
* If the message has a session id which the joiner has not constructed - the joiner will react as follows:
** ''Participant Info'': *** If the joiner is mentioned in the participant list, the joiner construct a session with that list.*** If the joiner is not mentioned in the plist, the joiner
ignore the message ( *** Should the joiner begins a session by appending itself to the list?).
** ''Session Confirmation'': The joiner will mark all sessions as DEAD and wait for the new participant list (*** should joiner send a new join request?).
If the message has session id corresponding to a session that the joiner already constructed (and is in process of joining, i.e. is not DEAD), then the session FSM will deal with the message, as stated above.
user_in_room_state == CURRENT_USER
* If the received message has a session id and the participant has constructed a session corresponding to that message. Then the FSM treats the message.
* If the received message has a session id, but the confirmed participant does not have a session is not part of the session then the participant will ignore the message, unless the message is of PARTICIPANT_INFO.
* If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line
see Session Transmission section.
* If the received message does not have a session id, then it is a JOIN_REQUEST
then the FSM of next_in_activation_line will treat the session . For the definition of next_in_activation_line see Session Transmission section.
next_in_activation_line is the session which receives requests for new session (join/leave). When new session is activated it also become next_in_activation_line. When a new priority session is constructed it takes the next_in_activation_line pointer. If there is no priority session, then the first session which gets it share key generated becomes the next in activtion.
When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.
Joining user (user_in_room_state == JOINING) does not keep any indicator.