Changes

Np1sec

1,854 bytes added, 7 years ago
/* VIII.10 (n+1)sec Session Management and Message Handling */
==VIII.10 (n+1)sec Session Management and Message Handling==
(n+1)sec secure conversations are modeled as chat sessions with proven cryptographic properties. A chat session starts with participants run the key agreement protocol and then agree and confirm a shared key.
This section explains However, the rule - based process on which - (n+1)sec governs the order when multiple how a joining and leaving participants try to join or leave a session simultaneously. Every participant in trigger a new chat room has either the status of a "joiner" or a "participant" of a confirmed session exclusively. Based on the user status sessions and the message received, a specific subprotocol needs how participants need to be run by respond to multiple simultanous joins and leaves requests and the user which process of establishing multiple chat sessions is explained in the following sectionsmanaged by (n+1)sec Session Management protocol.
If This protocol is work in progress to deal with unresponsive participants and those who denial their response to bar the establishment of a session. This section explains the rules - based on which - (n+1)sec currently 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 "confirmed 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. '''FSM message handling''': The basic rule is that 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, for users of joiner or confirmed participant status:
===Joiner===
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 a session - the joiner will react as followsbased on the typ of the message:
** '''Participant Info''': *** If the joiner is mentioned in the participant list, the joiner construct a session with that list. The session will be at the state of JOIN_REQUESTED.*** If the joiner is not mentioned in the plist, the joiner ignore ignores the message (*** Suggestion: Should the joiner begins a session by appending itself to the list?).
** '''Session Confirmation''': The joiner will mark all its 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
 
The confirmed participant is a member of a unique session in state of IN_SESSION. This session is indicated as '''active_session'''. All messages participants sends to the room is going to such session. The participant also keeps an indicator named as '''next_in_activation_line'''. Both indicators are pointing to the active_session at the point when the active_session moves to IN_SESSION state.
* 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 session 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 (otherwise marked as invalid). The FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.
===Session transition===
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. In this case, the session with leaving participant removed becomes the '''next_in_activation_line''' and all live sessions (not DEAD) (beside the active_session) will be marked as stale.  When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. That's the session will become the next_in_activation_line, and all live sessions (beside the active_session will bemarked as stale. When the next_in_activation_line session is confirmedand moves to IN_SESSION, the active_session moves to DEAD state. For each stale session, a new participant info list will be generated of the union of the participant in new active session and the participant in the stale session bar the users which left during in process of active_session establishment. The participants info message will be sent to the remaining joining users.
Joining user (user_in_room_state == JOINING) does not keep any indicator.