(Simplifies the protocol without involving confirmation) |
|||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=Proposal for concurrent join= | =Proposal for concurrent join= | ||
− | + | One can have the following protocol to handle concurrent join. | |
− | + | Each occupant can mark each session with one of the '''5 statuses: {current, in-limbo, dead}''' | |
− | '''current''': User messages are being encrypted and decrypted in the current session. The join request will be | + | '''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 | + | '''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 | + | '''dead''': The session is abandoned and not going to become the current session. |
− | The protocol | + | The protocol joins one user at a time but is greedy and non-blocking in respect to several concurrent joiners and eventually results in 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 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== | ==Session picking protocol for new user joining the room== | ||
− | New user | + | New user 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> | <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 | + | From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. When a session receives all shares, it computes the session key and becomes the current session. All other sessions can 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== | ==Session picking protocol for current occupant of the current session== | ||
− | Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>U_j</math> | + | Suppose user <math>U_i</math> is in Session <math>S</math>. When a new user <math>U_j</math> sends a join request, the user <math>U_i</math> starts a session in limbo <math>S_j</math> with the list of users in 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: |
<math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math> | <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> | + | 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 | + | 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 <math>S_j</math> is marked as dead. |
− | + | The user <math>U_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. All other <math>S_j</math> result in new sessions <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. Previous active (current) session of the room becomes in-limbo. | |
in-limbo -> {in-limbo, dead, current} | in-limbo -> {in-limbo, dead, current} | ||
current -> in-limbo | current -> in-limbo |
Latest revision as of 16:33, 13 March 2015
Proposal for concurrent join
One can have the following protocol to handle concurrent join.
Each occupant can mark each session with one of the 5 statuses: {current, in-limbo, dead} 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.
The protocol joins one user at a time but is greedy and non-blocking in respect to several concurrent joiners and eventually results in 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 for the protocol to succeed, which is a transport assumption for protocol.
Session picking protocol for new user joining the room
New user starts a join process by sending . In respose, it receives messages of the format
From each user . The joiner makes a session for each which contains them as a participant, the user initiates a session and gathers shares. When a session receives all shares, it computes the session key and becomes the current session. All other sessions can 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 is in Session . When a new user sends a join request, the user starts a session in limbo with the list of users in the current session plus the joining user. As part of initiation of each session the current user sends a message of type:
If users are joining that session concurrently, there are sessions in-limbo which are receiving shares and authentication messages.
If , currently in the session, signals to leave the room, a new session is created. Furthermore, each session in-limbo which has as participants, results in the creation of new session with user omitted and is marked as dead.
The user sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. All other result in new sessions to which is added. Previous active (current) session of the room becomes in-limbo.
in-limbo -> {in-limbo, dead, current} current -> in-limbo