search

livepeer / go-livepeer-basicnet

Basic p2p video streaming for Livepeer
MIT License
18 stars 8 forks source link

Routing Loops #37

Open j0sh opened 6 years ago

j0sh commented 6 years ago

So I'm not sure how we're actually populating our peer tables and whether that actually follows Kademlia routing specifications. Depending on how we do this, routing loops seem like they are a possibility in the current network protocol for nodes that are more than two hops apart. As an example, given the topology

A : { B, C }
B : { A, C }
C : { A, B, D }
D : { C, E }
E : { D }

and the xor-distance score to E (from A) being C > B > D > A > E.

Since we only send to the closest node, and exclude the peer that we received the message from, the route from A to E ends up looking like this: A -> B -> C -> A when it should be A -> B -> C -> D -> E

Are we certain that the network protocol will always converge? Should we track visited nodes as part of metadata that's sent with each directed message (SubReq, TranscodeSub, TranscodeResponse)?

One possibility is to bypass the problem altogether since we don't actually need DHT style routing overlays for broadcaster-transcoder interactions, with the requirement that transcoders are public (https://github.com/livepeer/go-livepeer-basicnet/issues/34).

ericxtang commented 6 years ago

You are correct in that we have an routing loop issue. There are some possible fixes, one being always caching the message for some period of time via a package like https://github.com/whyrusleeping/timecache.

rairyx commented 6 years ago

Caching messages to drop the repeated message? One other fix could be relayer sending message to all peers instead of sending only to the nearest peer, if there are redundant messages the receiver could drop it