View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005837 | secushare | groupchat | public | 2019-08-18 15:03 | 2021-02-08 03:39 |
| Reporter | lurchi | Assigned To | xrs | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | feedback | Resolution | open | ||
| Target Version | 0.1 | ||||
| Summary | 0005837: [RFC] Ring-based groupchat (serverless) | ||||
| Description | For the first release we should design and implement a protocols for establishing a ring topology. This is one of the simplest topologies that can be decentralized and self-organized. It would allow us to eliminate the server peer and conduct experiments with message relaying in real-world network conditions. Requirements: - Purely p2p, no "super nodes" - high availability of groups (99,95% downtime as a rough estimate) Architecture: - the pure p2p structure is achieved by sending group messages over cadet connections organized as a ring topology - high availability is achieved by to measures: - the topology is enriched by more links skipping direct neighbours to improve the reliability of message delivery - it's recommended that at least one group member runs a peer always on - group members use a distributed state State Information: - group ID - group name - list of members - list of group owners (just a flag in the member list) Process: Create group - group owner creates group ID and stores given group name - group owner adds given peer IDs as new group members - group members are sent an invitation message per cadet with the state information - group members send ack over group topology (or: back over cadet) Process: Send a message - create a message, create a message ID (random number), optionally a pointer to a previous message if desired - send a message to the next available group member following in the ordered list - receiving group member sends an ack back - the message is forwarded to the whole group and back to the sender who thereby gets a pseudo group confirmation Process: Add new group member - group owner sends invitation message per cadet containing the state information - new group member acknowledges membership by sending ack over group links (or back over cadet) - group owner sends new message with status information to group members Process: Disjoin (go offline) - group member just goes offline (FIXME: would be nice to have status information, thus notify) Process: Rejoin (go online) - group member requests state information from next group members in the ordered list - group member updates its state and can then send messages Process: join group - new peer sends join request at known group member - join request is forwarded to group owner - group owner decides on request; if positive, group owner sends an invitation message to the new peer Process: leave group - group member sends leave message - group owner sends new message with status information to group members Issues: - Scalability - Reliability - Latency - Multicast tree topology is more efficient than ring topology | ||||
| Tags | No tags attached. | ||||
|
|
Let's try a pattern of self-organization which is proposal making. 1. round: Present proposal/RFC (hereby done). 2. round: ask questions and get clarifications. Repeat if there are more questions. 3. round: make suggestions for improvement. The initiators will try to integrate those suggestions (or objections). 4. step: Obtain consent for a first sprint and celebrate :-) |
|
|
Do you think notifications for members leaving is even possible if every peer potentially hosts? I mean the other peers will most likely only know from which peer next to them certain messages came. So a direct connection between a disconnect-callback in CADET and a notification requires all peers tracking each other peer-ids. More problematic is the ring-structure or every non-centralized structure actually because multiple peers will recognize a disconnection at similar time. So multiple peers will notify about a member leaving even though only one connection could be closed and the member didn't actually fully disconnect. But one peer can not know about that without waiting for all notifications, hoping that the other connections are still valid... Let's imagine: A, B, C, D and E are a ring (A<->B, B<->C, C<->D, D<->E, E<->A) A and D disconnect... ..now B misses A, C misses D and E misses A and D but B and C don't know E is still in the group... it's similar for E. B, C and E can now guess who is disconnected (sending potentially false notifications) or trying to reconnect to missing peers until a timeout comes up. the problem with the timeout is that between A and D could be only one peer E but there could also be thousands... ..and false notifications are quite annoying to handle. The next problem is that peers could lie about others disconnecting. This could allow manipulating a different peer to ping a huge amount of other members. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-08-18 15:03 | lurchi | New Issue | |
| 2019-08-18 15:07 | lurchi | Summary | Establish ring topology (and eliminate server) => [PROPOSAL] Establish ring topology (and eliminate server) |
| 2019-08-18 15:07 | lurchi | Description Updated | |
| 2019-08-18 15:54 | xrs | Relationship added | parent of 0005841 |
| 2019-08-18 16:42 | xrs | Relationship added | parent of 0005843 |
| 2019-08-18 16:43 | xrs | Relationship added | parent of 0005842 |
| 2019-08-27 21:57 | xrs | Summary | [PROPOSAL] Establish ring topology (and eliminate server) => [RFC] Ring-based groupchat (serverless) |
| 2019-08-27 21:57 | xrs | Description Updated | |
| 2019-08-27 22:03 | xrs | Description Updated | |
| 2019-08-27 22:07 | xrs | Description Updated | |
| 2019-08-27 22:15 | xrs | Description Updated | |
| 2019-08-27 22:28 | xrs | Description Updated | |
| 2019-08-27 22:37 | xrs | Assigned To | => xrs |
| 2019-08-27 22:37 | xrs | Status | new => feedback |
| 2019-08-27 22:37 | xrs | Note Added: 0014819 | |
| 2021-02-08 03:39 | thejackimonster | Note Added: 0017509 |
