chat-wane / rtc-scamp-mbr Goto Github PK

Currently, the callback argument of the answer function creates side effects over prior answer functions.

For instance, if you call 3 times the answer function with 3 different callbacks:
scamp.answer(messageA, functionA); scamp.answer(messageB, functionB); scamp.answer(messageC, functionC);
Since the protocol executed is not instant, and since only one callback is registered (the last), functionC may be called instead of functionA and functionB...

TODO: each callback has a unique identifier. The latter allows to retrieve the proper function when the answer protocol is over.

Currently, it uses the vector that aimed to generate unique identifiers. However, since all messages are not meant to everyone, it creates gap in a vector.

TODO: split the unique identifiers of messages meant to be broadcast (maybe without vector structures), and the one of the membership (with vectors). Or... broadcast messages do not have unique identifiers, instead, they have a hop number which monotonically decreases. When it becomes zero, the message is not broadcast anymore. The latter approach scales in number of users, nevertheless, the number of hop is difficult to set and can bring delivery issues. Also, it floods the network.

Currently, one offer is dispatched per neighbour in the partialView of the contact peer. However, there are normally more offers to dispatch in order to handle failures. Each offer should be eventually accepted, but when the global network is small, some subscription can loop in the network without beeing accepted because the peers already knows the subscribing peer.

In the paper, a peer discards the subscription request when it forwarded it 10 times.

Currently, when a peer leaves the network (because crashes or voluntarily quits), no change are made in partialView and inView.
Thus, broadcasting generates errors because it cannot reach the peer.

Without implementing specifically the SCAMP protocol for this kind of situation (i.e. rebalancing and so on), at least, the peer must be delete from the views.

Currently, each "Conf.weightUpdate" time, peers update the weight of their incoming/outgoing arcs ( Used in the indirection mechanism of SCAMP ). Then it sends the weight to the corresponding peer. However, it only requires to send if the weight is actually updated.

Easy to improve.

Currently, SCAMPjs provides each peer with an identity supposedly unique. However, it only randomizes an integer within a range (very thin for now). Thus, there is a probability that two peers get the same identifiers and that may creates problems.

TOFIX: Maybe consider a way that the first peer gets its identifiers from a peer within the network. Each peer gets an allocating range for new peers (from bounded, or dotted version vector I think?). For instance, the first peer got the identifier 0 and an allocation range [1..100], a second peer connects to it. This peer gets 50 has UID and can allocate identifiers from 51..100. Now the first peer can allocates identifiers from 1..49 and so on. When the allocating range becomes empty, the set of identifiers is enlarged by creating a branch. For instance the first peer could allocate identifiers has [ 0 , X ] where X is the new allocating range. New peers connecting to the first peer would get unique identifiers since only this peer provides identifiers prefixed with "0".

TOTHINK: the aforementioned uids may grow quickly -> use exponential tree ?

SCAMP uses a lease mechanism: after a while, a link becomes stale and must be replaced in order to rebalance the views.

Without it, newly joined peers have a partialView of 1 peer only, which increases the risk of disconnections due to failures. With this mechanism, the new peer will receive subscriptions requests and therefore, will add peers to its partialView.

Currently, when a peer subscribe to the network, it sends multiple offers that are forwarded to the network.
When a peer accept an offer, it has to generate an offer back (which takes "Conf.waitSTUN" time, issue #2). In the meantime, it can accept other offers of this peer. Therefore, the peer would have multiple times the new peer in its partialView when it should have it at most once.

TODO: look into the pending table if an offer has been created for the new peer already.

Currently, a peer A that wants to enter the network must produce a subscription request and give it to another peer B inside the network. The, the peer B may forward the subscription request to the rest of the network. Eventually a peer within the network (which can be the peer B) accepts the subscription request and backtracks its response to the peer B. Finally the peer B must give the subscription to the peer A, and the requesting peer and responding peer can handshake.

Now, if several peers wants to join simultaneously the network, each response must be carefully associated with the peer that requested it ( which is not in the html example).

The thing can be achieved by using the unique site identifier and counter of the request, which is also contained in the response message.

For now, the joining procedure is initiated by the peer outside the network. The other way around works too, but does not preserve the desired properties of the network.
Consequently, a peer inside the network should be able to invite someone else to join. It implies that the underlying indirection mechanism works too. It also implies that the answer provided by the peer outside the network correctly travels to the chosen peer inside the network.

A peer regularly receives heartbeat message to signal that the emitter is still alive. If a peer does not receive this message for a while, it means that the emitting peer is dead and must be deleted from the inView.

TODO: check if webrtc/simple-peer link does not send these heartbeat messages already and raises an "error" event in case of failure.

Add basic functionalities to know the state of the node: connected, partially connected (i.e. has a link within its partialView or inView but not both), disconnected.

The partially connected state can also help to reconnect to the network and retrieve a connected state.

Currently, a peer can enter the network using a piece of data provided by WebRTC stun server. Thus, a peer can connect to multiple peers at a time. However, it does not update its partialView and inView. As a consequence, it cannot broadcast messages using the partialView.

SCAMP uses an indirection mechanism. This mechanism aims to alleviates the fact that one peer only handle a lot of subscription request by himself.
Indeed, the first subscription node must be chosen at random among the set of all nodes in order to keep uniform partialViews and inViews. To do so, a peer periodically updates a weight associated with each node in its views and, when a new first subscription arrives, it forwards the subscriptions to one of peers in its partialView with a probability depending on the weights.

Currently, to retrieve the piece of WebRTC data required to establish connection between two peers, there is a timeout(3000) before sending in order to wait and make a one-message package of the signaling data.

TODO: find a less ad-hoc way to get the signaling data and stop the waiting process.