Changes

Np1sec/concurrent join

68 bytes added, 5 years ago
/* Proposal for concurrent join */
=Proposal for concurrent join=
One can have the following protocol to handle concurrent join.
each Each occupant can mark each session with one of the '''5 statusstatuses: {current, in-limbo, dead}''''''current''': User messages are being encrypted and decrypted in the current session. The join request will be process processed by this session.'''in-limbo''': A session which is receiving shares and confirmation, this session can potentially become the next session if it receive receives session confirmation from all users.'''dead''': The session is abonden abandoned and not going to become the current session.
The protocol join joins one user at the a time but is greedy and non-blocking in respect to several concurrent joiner joiners and eventually results in join joins of all new users (as long as current users in the session cooperate with the join process). The global order of messages is essential in for the protocol to succeed , which is a transport assumption for <math>n+1sec</math> protocol.
==Session picking protocol for new user joining the room==
New user start starts a join process by sending <math>(U_{joiner}, y_{joiner})</math>. In respose, it receives messages of the format
<math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
'''From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contain contains them as a participant, the user initiate initiates a session and gather gathers shares. When a session receives all shares , it compute computes the session key becomes the current session. ''' All other session sessions can remains remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
==Session picking protocol for current occupant of the current session==
Suppose user <math>U_i</math> is in Session <math>S</math>. When a new user <math>U_j</math> send sends a join request, the user <math>U_i</math> start starts a session in limbo <math>S_j</math> with the list of users in the current session plus the joining user. As a part of initiation of each session <math>S_j</math> the current user send sends a message of type:
<math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> sessions in-limbo which are receiving shares and authentication messages.
'''If the <math>U_l</math> currently in room signal to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in the creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead. '''
User The user <math>U_i</math> send sends the shares and authentication token necessary for each session. The first session which receives all confirmation confirmations will become the main session, and the joiner user of that session becomes the current session. '''All other <math>S_j</math> results in new session <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.'''
in-limbo -> {in-limbo, dead, current}
current -> in-limbo