Changes

Np1sec/concurrent join

386 bytes added, 9 years ago
=Proposal for concurrent join=
With having session key confirmation one One can have the following protocol to handle concurrent join.
Each session occupant can have mark each session with one of the '''5 statusstatuses: {current, potentially nextin-limbo, next, admissible, inadmissibledead}''''''current''': User messages are being encrypted and decrypted in the current session. The join request will be processed by this session.'''in-limbo''': A session which is receiving shares and confirmations, this session can potentially become the next session if it receives session confirmation from all users.'''dead''': The session is abandoned and not going to become the current session.
==Session picking The protocol for current occupant of the current session==Suppose joins one user <math>U_i</math> at a time but is greedy and non-blocking in respect to several concurrent joiners and eventually results in Session <math>S</math>. When joins of all new user <math>Unew_j</math> send a users (as long as current users in the session cooperate with the join requestprocess). The global order of messages is essential for the protocol to succeed, user which is a transport assumption for <math>U_in+1sec</math> start an admissible session <math>S_j</math> with the list of authenticated participant in the room (not users in the session)protocol.
If ==Session picking protocol for new user joining the room==New user starts a join process by sending <math>m(U_{joiner}, y_{joiner})</math> users are joining that session concurrently, there are <math>S_1,...In respose,S_m</math> admissible which are receiving shares and authentication it receives messages.of the format
Suppose <math>S_j</math> receives the mutual authentication of all new users in admissible session <math>S_j</math> that will become the potentially next session of <math>U_i</math>. <math>U_i</math> then sends the combined list of (authenticated) participants in <math>S_j</math>sid, <math>(U_1,y_1,...,Unew_mU_{joiner},ynew_my_{joiner},...)</math> to the room intending for new users not in the list to see and to authenticate to, and to old user to signal its potentially next session. It tags <math>S_1,...kc_{i},S_mz_{i}</math> as inadmissible sessions.
When From each user <math>U_ii</math> receives all shares of potentially next . The joiner makes a session for each <math>S_jsid</math> which contains them as a participant, the user initiates a session and the authenticated list from gathers shares. When a session receives all users from current sessionshares, they tag it computes the session as next key and send becomes the current session key confirmation of <math>S_j</math>. The session will not be tagged as inadmissible All other sessions can remain in case limbo or get discarded based on the memory capacity of new authenticated list, it just make new admissible sessionthe implementation and security requirement.
If ==Session picking protocol for current occupant of the current session==Suppose user <math>U_i receives another authenticated list from another </math>S_j'is in Session <math>S</math> then it tag . When a new user <math>S_jU_j</math> inadmissible as well and start an admissible sends a join request, the user <math>U_i</math> starts a session with in limbo <math>plist_{S_j'} \cup plist_{S_j}</math> as new admissible session waiting for authentication from new with the list of usersin the current session plus the joining user.As part of initiation of each session <math>S_j</math> the current user sends a message of type:
If it receives key confirmation from all <math>U_l</math> in <math>sid, (U_1,y_1,...,Unew_mU_{joiner},y_{joiner},...), kc_{i}, z_{i}</math> then it will make <math>S_j</math> as current session and send messages to this session.
==Session picking protocol for new user joining the room==
When a joining user Unew_l receives a list of potential users which is not including them, it authenticate to U_i's which new user has not yet authenticated to, and compute new share for the new share list. When they have all shares and authentication for plist_j then they send the key confirmation and wait for all of key confirmation.
When they receive confirmation from every user If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> sessions in plist_j-limbo which are receiving shares and authentication messages. They make it current  If <math>U_l</math>, currently in the session , signals to leave the room, a new session <math>S_l</math> is created. Furthermore, each session <math>S_j</math> in-limbo which has <math>U_l</math> as participants, results in the creation of new session <math>S_{j'}</math> with user <math>U_l</math> omitted and start chatting<math>S_j</math> is marked as dead.
admissible -The user <math> {inadmissibleU_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, potentially next}potentially next -and the joiner user of that session becomes the current session. All other <math>S_j</math> result in new sessions <math>S_{inadmissible, nextj''}next-</math>to which <math>U_{currentjoiner}</math> is added. Previous active (current) session of the room becomes in-limbo.
in-limbo -> {in-limbo, dead, current and inadmissible will be eventually discarded.}current -> in-limbo