View Issue Details

IDProjectCategoryView StatusLast Update
0005837secusharegroupchatpublic2021-02-08 03:39
Reporterlurchi Assigned Toxrs  
PrioritynormalSeverityminorReproducibilityhave not tried
Status feedbackResolutionopen 
Target Version0.1 
Summary0005837: [RFC] Ring-based groupchat (serverless)
DescriptionFor 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.

- Purely p2p, no "super nodes"
- high availability of groups (99,95% downtime as a rough estimate)

- 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

- Scalability
- Reliability
- Latency
- Multicast tree topology is more efficient than ring topology
TagsNo tags attached.


parent of 0005841 new Add method for creating a group 
parent of 0005843 new Create distributed state protocol 
parent of 0005842 new Create method for sending a message 
Not all the children of this issue are yet resolved or closed.



2019-08-27 22:37

manager   ~0014819

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 :-)


2021-02-08 03:39

reporter   ~0017509

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... 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.

Issue History

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