Routing Loops
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- go
- Ambito
- distributed-systems, networking
Direzione di ricerca
Inizia tracciando come vengono popolate le tabelle dei peer e come vengono instradati SubReq, TranscodeSub e TranscodeResponse; confronta questo comportamento con la questione del routing Kademlia sollevata qui. Determina se sono necessari metadati sui nodi visitati o l’approccio del transcoder pubblico dell’issue #34, e definisci come completamento una decisione di protocollo che impedisca il loop A-B-C-A.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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).
- Lingua principale
- Go
- Stelle
- 18
- Fork
- 6
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di livepeer/go-livepeer-basicnet
-
Transcoder error feedbackAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
livepeer/go-livepeer-basicnet#39 · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
livepeer/go-livepeer-basicnet#34 · 3 commenti · 2 reazioni ·
-
Code generation for messagesAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
livepeer/go-livepeer-basicnet#33 · 5 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
livepeer/go-livepeer-basicnet#31 · 5 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
Tutte le issue di livepeer/go-livepeer-basicnet
Issue simili
-
area/proxy kind/bug priority/backlog triage/accepted
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
lexfrei/cloudflare-tunnel-gateway-controller#840 ·
I maintainer di solito rispondono entro 1 giorno
-
area:chat bug sev:papercut
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
Agent-Field/CodeAF#1592 ·
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 7 giorni
-
bug needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug P2 reliability
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
afreidah/s3-orchestrator#1564 ·
I maintainer di solito rispondono entro 1 giorno