Routing Loops
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- go
- Lĩnh vực
- distributed-systems, networking
Hướng nghiên cứu
Bắt đầu bằng cách lần theo cách các bảng peer được điền và cách SubReq, TranscodeSub cùng TranscodeResponse được định tuyến; so sánh hành vi đó với câu hỏi về định tuyến Kademlia được nêu ở đây. Xác định xem có cần siêu dữ liệu về các node đã truy cập hay cách tiếp cận transcoder công khai từ issue #34 hay không, và coi là hoàn thành khi có một quyết định ở cấp giao thức ngăn vòng lặp A-B-C-A.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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).
- Ngôn ngữ chính
- Go
- Star
- 18
- Fork
- 6
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của livepeer/go-livepeer-basicnet
-
Transcoder error feedbackĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
livepeer/go-livepeer-basicnet#39 · 1 reaction ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
livepeer/go-livepeer-basicnet#34 · 3 bình luận · 2 reaction ·
-
Code generation for messagesĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
livepeer/go-livepeer-basicnet#33 · 5 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
livepeer/go-livepeer-basicnet#31 · 5 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Tất cả issue của livepeer/go-livepeer-basicnet
Issue tương tự
-
area/proxy kind/bug priority/backlog triage/accepted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
lexfrei/cloudflare-tunnel-gateway-controller#840 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:chat bug sev:papercut
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Agent-Field/CodeAF#1592 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
kind/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 7 ngày
-
bug needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug P2 reliability
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
afreidah/s3-orchestrator#1564 ·
Maintainer thường phản hồi trong vòng 1 ngày