네트워크 데이터베이스 토론

참고: 다음은 netDb 구현의 역사에 대한 논의로 현재 정보가 아닙니다. 현재 문서는 메인 netDb 페이지 를 참조하세요.

히스토리

netDb는 “floodfill"이라는 간단한 기법으로 분산됩니다. 오래전에는 netDb가 Kademlia DHT를 대체 알고리즘으로 사용하기도 했습니다. 하지만 우리 애플리케이션에서 제대로 작동하지 않아서 0.6.1.20 릴리스에서 완전히 비활성화되었습니다.

(2005년 11월 26일 구 Syndie에서 jrandom이 작성한 글에서 각색)

floodfill netDb는 실제로는 단순하고 아마도 임시적인 조치일 뿐이며, 가능한 가장 간단한 알고리즘을 사용합니다 - floodfill netDb의 피어에게 데이터를 보내고, 10초를 기다린 후, netDb에서 무작위 피어를 선택하여 전송될 항목을 요청하고, 적절한 삽입/배포를 확인합니다. 확인 피어가 응답하지 않거나 해당 항목을 가지고 있지 않으면, 발신자는 이 과정을 반복합니다. floodfill netDb의 피어가 floodfill netDb에 속하지 않은 피어로부터 netDb store를 받으면, floodfill netDb의 모든 피어에게 이를 전송합니다.

한때 Kademlia 검색/저장 기능이 여전히 작동하고 있었습니다. 피어들은 floodfill 피어를 netDb에 참여하지 않는 다른 피어보다 모든 키에 대해 항상 ‘더 가까운’ 것으로 간주했습니다. floodfill 피어가 어떤 이유로든 실패할 경우 Kademlia netDb로 대체했습니다. 하지만 이후 Kademlia는 완전히 비활성화되었습니다(아래 참조).

최근에는 각 floodfill router가 저장해야 하는 netDb의 크기를 제한하는 방법으로 2009년 말에 Kademlia가 부분적으로 다시 도입되었습니다.

Floodfill 알고리즘의 소개

Floodfill은 릴리스 0.6.0.4에서 도입되었으며, Kademlia를 백업 알고리즘으로 유지하고 있습니다.

(2005년 11월 26일 구 Syndie에서 jrandom이 작성한 게시물에서 발췌)

제가 자주 말했듯이, 저는 특정 기술에 특별히 매여있지 않습니다 - 중요한 것은 결과를 얻을 수 있는 것입니다. 지난 몇 년간 다양한 netDb 아이디어들을 연구해왔지만, 지난 몇 주간 직면한 문제들로 인해 일부 아이디어들이 중요한 시점에 와있습니다. 실제 네트워크에서 netDb 중복 요소를 4개 peer로 설정하고(즉, 4개 peer가 수신을 확인할 때까지 새로운 peer들에게 계속 항목을 전송) peer당 타임아웃을 해당 peer의 평균 응답 시간의 4배로 설정했음에도 불구하고, 4개가 저장을 ACK하기 전까지 여전히 평균 40-60개의 peer에게 전송하고 있습니다. 이는 전송되어야 하는 것보다 36-56배 더 많은 메시지를 보내는 것을 의미하며, 각각은 tunnel을 사용하여 2-4개의 링크를 거칩니다. 더 나아가, 이 값은 심하게 편향되어 있는데, ‘실패한’ 저장(60초간 메시지를 보낸 후 4명 미만이 메시지를 ACK한 경우)에서 전송된 peer의 평균 수는 130-160개 범위였습니다.

이는 말이 안 되는데, 특히 고작 250개 정도의 peer만 있는 네트워크에서는 더욱 그렇습니다.

가장 간단한 답은 “음, 당연히 jrandom, 망가졌으니까 고치면 되지"라고 말하는 것이지만, 그것으로는 문제의 핵심에 도달하지 못합니다. 현재 진행 중인 다른 노력과 마찬가지로, 제한된 경로로 인해 상당수의 네트워크 문제가 발생하고 있을 가능성이 높습니다 - NAT나 방화벽 문제로 인해 일부 다른 피어와 통신할 수 없는 피어들 말입니다. 예를 들어, 특정 netDb 항목에 가장 가까운 K개의 피어들이 ‘제한된 경로’ 뒤에 있어서 netDb store 메시지는 도달할 수 있지만 다른 피어의 netDb lookup 메시지는 도달할 수 없다면, 해당 항목은 본질적으로 접근 불가능하게 됩니다. 이러한 방향을 조금 더 따라가보고 일부 제한된 경로가 악의적인 의도로 생성될 것이라는 사실을 고려하면, 장기적인 netDb 솔루션을 더 면밀히 살펴봐야 한다는 것이 분명합니다.

몇 가지 대안이 있지만, 특히 언급할 만한 두 가지가 있습니다. 첫 번째는 전체 네트워크의 하위 집합을 사용하여 netDb를 Kademlia DHT로 간단히 실행하는 것입니다. 여기서 모든 피어들은 외부에서 접근 가능합니다. netDb에 참여하지 않는 피어들은 여전히 해당 피어들에게 쿼리하지만, 요청하지 않은 netDb store 또는 lookup 메시지는 받지 않습니다. netDb 참여는 자기 선택적이면서 사용자 제거 방식이 될 것입니다 - router들은 참여를 원하는지를 나타내는 플래그를 자신의 routerInfo에 게시할지 선택하고, 각 router는 netDb의 일부로 취급하고 싶은 피어를 선택합니다 (해당 플래그를 게시하지만 유용한 데이터를 전혀 제공하지 않는 피어들은 무시되어, 본질적으로 netDb에서 제거됩니다).

또 다른 대안은 과거로의 회귀로, DTSTTCPW (Do The Simplest Thing That Could Possibly Work) 사고방식으로 돌아가는 것입니다 - floodfill netDb를 사용하되, 위의 대안과 마찬가지로 전체 네트워크의 부분집합만을 사용하는 것입니다. 사용자가 floodfill netDb에 항목을 게시하려고 할 때, 참여하는 router 중 하나에 간단히 전송하고, ACK를 기다린 후, 30초 후에 floodfill netDb의 다른 임의 참여자에게 질의하여 제대로 배포되었는지 확인합니다. 제대로 되었다면 좋고, 그렇지 않다면 과정을 반복하면 됩니다. floodfill router가 netDb store를 받으면, 즉시 ACK하고 알려진 모든 netDb 피어들에게 netDb store를 대기열에 추가합니다. floodfill router가 netDb lookup을 받으면, 데이터가 있으면 그것으로 응답하지만, 없으면 floodfill netDb의 다른 피어 20개 정도의 해시로 응답합니다.

네트워크 경제학 관점에서 보면, floodfill netDb는 원래의 브로드캐스트 netDb와 매우 유사하지만, 항목 게시 비용이 게시자가 아닌 netDb 내의 피어들이 주로 부담한다는 점에서 다릅니다. 이를 조금 더 자세히 설명하고 netDb를 블랙박스처럼 취급하면, netDb에 필요한 총 대역폭을 다음과 같이 볼 수 있습니다:

recvKBps = N * (L + 1) * (1 + F) * (1 + R) * S / T

여기서:

N = number of routers in the entire network
L = average number of client destinations on each router
    (+1 for the routerInfo)
F = tunnel failure percentage
R = tunnel rebuild period, as a fraction of the tunnel lifetime
S = average netDb entry size
T = tunnel lifetime

몇 가지 값을 대입하면:

recvKBps = 1000 * (5 + 1) * (1 + 0.05) * (1 + 0.2) * 2KB / 10m
         = 25.2KBps

이는 결국 N에 선형적으로 비례합니다 (100,000개의 피어에서 netDb는 총 2.5MBps의 netDb 저장 메시지를 처리할 수 있어야 하며, 300개의 피어에서는 7.6KBps입니다).

floodfill netDb에서는 각 netDb 참가자가 클라이언트가 생성한 netDb 저장소의 일부분만 직접 받게 되지만, 결국 모든 항목을 받게 되므로, 모든 링크가 전체 recvKBps를 처리할 수 있어야 합니다. 차례로, 다른 피어들과 동기화를 유지하기 위해 (recvKBps/sizeof(netDb)) * (sizeof(netDb)-1)만큼 전송해야 합니다.

floodfill netDb는 netDb 운영을 위한 터널 라우팅이나 ‘안전하게’ 응답할 수 있는 항목을 선택하는 특별한 과정이 필요하지 않습니다. 기본 가정은 모든 노드가 모든 것을 저장하고 있다는 것이기 때문입니다. 그리고 netDb 디스크 사용량과 관련해서는, 최신 머신에서는 여전히 매우 사소한 수준으로 피어 1000개당 약 11MB가 필요합니다 (N * (L + 1) * S).

Kademlia netDb는 이러한 수치들을 줄일 수 있으며, 이상적으로는 K over M배만큼 줄일 수 있습니다. 여기서 K는 중복 계수이고 M은 netDb 내 router 수입니다 (예: 5/100, 100,000개 router에서 recvKBps 126KBps와 536MB). 하지만 Kademlia netDb의 단점은 적대적인 환경에서 안전하게 운영하기 위한 복잡성이 증가한다는 것입니다.

지금 제가 생각하고 있는 것은 기존 라이브 네트워크에 floodfill netDb를 간단히 구현하고 배포하여, 이를 사용하고자 하는 피어들이 멤버로 플래그가 지정된 다른 피어들을 선택하고 기존 Kademlia netDb 피어들 대신 이들을 쿼리하도록 하는 것입니다. 현 단계에서 대역폭과 디스크 요구사항은 충분히 미미하며(7.6KBps와 3MB 디스크 공간), 이를 통해 디버깅 계획에서 netDb를 완전히 제거할 수 있습니다 - 여전히 해결해야 할 문제들은 netDb와 관련 없는 다른 원인에 의한 것일 것입니다.

floodfill netDb의 일부라고 말하는 플래그를 게시할 peer들은 어떻게 선택될까요? 처음에는 고급 설정 옵션으로 수동으로 수행할 수 있습니다 (router가 외부 도달 가능성을 확인할 수 없는 경우 무시됨). 너무 많은 peer들이 해당 플래그를 설정하면, netDb 참가자들은 어떤 것들을 제거할지 어떻게 선택할까요? 다시 말해, 처음에는 (도달할 수 없는 peer들을 제거한 후) 고급 설정 옵션으로 수동으로 수행할 수 있습니다. netDb 분할을 어떻게 피할 수 있을까요? router들이 K개의 무작위 netDb peer들에게 쿼리를 보내서 netDb가 flood fill을 제대로 수행하고 있는지 확인하도록 하면 됩니다. netDb에 참여하지 않는 router들은 tunnel을 통과할 새로운 router들을 어떻게 발견할까요? 아마도 특정한 netDb 조회를 보내서 netDb router가 netDb 내의 peer들이 아닌 netDb 외부의 무작위 peer들로 응답하도록 할 수 있을 것입니다.

I2P의 netDb는 기존의 부하 분산 DHT와 매우 다릅니다 - 실제 페이로드가 아닌 네트워크 메타데이터만을 전달하므로, floodfill 알고리즘을 사용하는 netDb라도 임의의 양의 I2P Site/IRC/bt/mail/syndie 등 데이터를 지속적으로 처리할 수 있습니다. I2P가 성장함에 따라 해당 부하를 좀 더 분산시키기 위한 최적화도 수행할 수 있습니다 (아마도 netDb 참가자들 간에 블룸 필터를 전달하여 공유해야 할 항목을 확인하는 방식으로), 하지만 현재로서는 훨씬 더 간단한 솔루션으로 충분해 보입니다.

한 가지 깊이 살펴볼 만한 사실은 모든 leaseSet이 netDb에 게시될 필요가 없다는 것입니다! 실제로 대부분은 게시할 필요가 없으며, 요청하지 않은 메시지를 받을 목적지(즉, 서버)에 대한 것들만 필요합니다. 이는 한 목적지에서 다른 목적지로 전송되는 garlic로 감싸진 메시지가 이미 발신자의 leaseSet을 포함하고 있어서, 해당 두 목적지 간의 후속 송수신이 (짧은 시간 내에) netDb 활동 없이도 작동하기 때문입니다.

따라서 앞의 방정식들로 돌아가서, L을 5에서 0.1과 같은 값으로 변경할 수 있습니다 (50개 목적지 중 1개만이 서버라고 가정). 이전 방정식들은 또한 클라이언트의 쿼리에 응답하는 데 필요한 네트워크 로드를 간과했지만, 이는 매우 가변적이긴 하지만 (사용자 활동에 따라) 게시 빈도에 비해 상당히 미미할 가능성이 높습니다.

어쨌든, 여전히 마법은 없지만 필요한 대역폭/디스크 공간을 거의 1/5 가량 줄일 수 있는 좋은 개선입니다 (routerInfo 배포가 피어 연결 과정의 일부로 직접 이루어지는지 아니면 netDb를 통해서만 이루어지는지에 따라 나중에 더 줄어들 수도 있습니다).

Kademlia 알고리즘의 비활성화

Kademlia는 릴리스 0.6.1.20에서 완전히 비활성화되었습니다.

(jrandom과의 IRC 대화에서 각색, 11/07)

Kademlia는 계층을 추가한 후에도 기본선이 제공할 수 없는 최소 수준의 서비스(대역폭, CPU)를 요구합니다(순수한 kad는 그 점에서 말이 안 됩니다). Kademlia는 작동하지 않을 것입니다. 좋은 아이디어였지만, 적대적이고 유동적인 환경에는 적합하지 않았습니다.

현재 상태

netDb는 I2P 네트워크에서 매우 특정한 역할을 하며, 알고리즘은 우리의 필요에 맞게 조정되었습니다. 이는 또한 아직 마주하지 않은 필요사항들을 해결하기 위해 조정되지 않았다는 의미이기도 합니다. I2P는 현재 상당히 작습니다(수백 개의 router). 3-5개의 floodfill router가 네트워크의 10,000개 노드를 처리할 수 있다는 계산이 있었습니다. netDb 구현은 현재 우리의 필요를 충분히 만족시키고 있지만, 네트워크가 성장함에 따라 추가적인 튜닝과 버그 수정이 필요할 것으로 보입니다.

계산 업데이트 03-2008

현재 수치:

recvKBps = N * (L + 1) * (1 + F) * (1 + R) * S / T

여기서:

N = number of routers in the entire network
L = average number of client destinations on each router
    (+1 for the routerInfo)
F = tunnel failure percentage
R = tunnel rebuild period, as a fraction of the tunnel lifetime
S = average netDb entry size
T = tunnel lifetime

가정의 변경사항:

• L은 i2psnark와 다른 앱들의 인기로 인해 위의 .1과 비교하여 현재 약 .5입니다.
• F는 약 .33이지만, tunnel 테스팅의 버그들이 0.6.1.33에서 수정되어 훨씬 개선될 것입니다.
• netDb는 약 2/3가 5K routerInfo들이고 1/3가 2K leaseSet들이므로, S = 4K입니다. RouterInfo 크기는 불필요한 통계를 제거함에 따라 0.6.1.32와 0.6.1.33에서 줄어들고 있습니다.
• R = tunnel 빌드 주기: 0.2는 매우 낮은 값이었습니다 - 아마 0.7 정도였을 것입니다 - 하지만 0.6.1.32의 빌드 알고리즘 개선으로 네트워크가 업그레이드되면서 약 0.2까지 낮아질 것입니다. 네트워크의 절반이 .30 또는 이전 버전에 있는 현재는 0.5라고 할 수 있습니다.

recvKBps = 700 * (0.5 + 1) * (1 + 0.33) * (1 + 0.5) * 4KB / 10m
         ~= 28KBps

이는 단지 저장소에 대한 것입니다 - 쿼리는 어떨까요?

Kademlia 알고리즘의 회귀?

(2007년 1월 2일 I2P 회의에서 발췌)

Kademlia netDb가 제대로 작동하지 않았습니다. 영구적으로 중단된 것인지, 아니면 다시 돌아올 것인지요? 만약 다시 돌아온다면, Kademlia netDb의 피어들은 네트워크 내 router들의 매우 제한된 부분집합이 될 것입니다 (기본적으로 floodfill 피어들의 확장된 수, floodfill 피어들이 부하를 처리할 수 없을 때). 하지만 floodfill 피어들이 부하를 처리할 수 있는 한 (그리고 처리할 수 있는 다른 피어들을 추가할 수 있는 한), 이는 불필요합니다.

Floodfill의 미래

(jrandom과의 IRC 대화에서 발췌, 11/07)

제안이 하나 있습니다: 용량 클래스 O는 자동으로 floodfill이 됩니다. 음. 확실하지 않다면, 모든 O 클래스 router들을 DDoS하는 멋진 방법이 될 수도 있습니다. 이것이 바로 그 경우입니다: 충분한 도달 가능성을 제공하면서도 floodfill 수를 가능한 한 적게 유지하고 싶습니다. netDb 요청이 실패할 때/경우에는 floodfill 피어의 수를 늘려야 하지만, 현재로서는 netDb 페치 문제를 인지하지 못하고 있습니다. 제 기록에 따르면 “O” 클래스 피어가 33개 있습니다. 33개는 floodfill로 하기에는 /너무/ 많습니다.

그러면 floodfill은 해당 풀의 피어 수가 확실히 제한될 때 가장 잘 작동하나요? 그리고 네트워크 자체가 점진적으로 성장하더라도 floodfill 풀의 크기는 크게 늘어나지 않아야 하는 건가요? 3-5개의 floodfill 피어가 10K개의 router를 처리할 수 있다고 기억합니다(이전 syndie에서 세부 사항을 설명하는 많은 수치를 게시했습니다). 자동 opt-in으로는 충족하기 어려운 요구사항인 것 같습니다. 특히 opt-in하는 노드가 다른 노드로부터의 데이터를 신뢰할 수 없는 경우 말입니다. 예를 들어 “내가 상위 5위 안에 드는지 확인해보자"라고 하면서, 자신에 대한 데이터만 신뢰할 수 있는 상황입니다(예: “나는 확실히 O 클래스이고, 150 KB/s로 움직이며, 123일간 가동 중이다”). 그리고 상위 5위도 적대적입니다. 기본적으로 이는 tor directory 서버와 같습니다 - 신뢰할 수 있는 사람들(즉, 개발자들)에 의해 선택되는 것이죠. 맞습니다, 지금은 opt-in에 의해 악용될 수 있지만, 이는 감지하고 처리하기가 쉬울 것입니다. 결국 Kademlia보다 더 유용한 것이 필요하고, 합리적으로 유능한 피어들만 해당 체계에 참여하도록 해야 할 것 같습니다. N 클래스 이상이면 적대자가 서비스 거부를 일으킬 위험을 억제할 수 있을 만큼 충분한 양이 될 것으로 희망합니다. 하지만 그렇다면 엄청난 트래픽을 발생시키지 않는다는 의미에서 floodfill과는 달라야 할 것입니다. 대량? DHT 기반 netDb에 대해서? 반드시 DHT 기반일 필요는 없습니다.

Floodfill TODO 목록

참고: 다음은 최신 정보가 아닙니다. 현재 상태와 향후 작업 목록은 주요 netDb 페이지 를 참조하세요.

2008년 3월 13일 약 2시간 동안(대략 18:00 - 20:00 UTC) 네트워크에 floodfill이 단 하나만 남아있었고, 이로 인해 많은 문제가 발생했습니다.

0.6.1.33에서 구현된 두 가지 변경사항은 floodfill 피어 제거 또는 이탈로 인한 중단을 줄여야 합니다:

1. 매번 검색에 사용되는 floodfill peer들을 무작위화합니다. 이렇게 하면 결국 실패하는 peer들을 우회할 수 있습니다. 이 변경사항은 또한 ff 검색 코드를 때때로 혼란스럽게 만들던 심각한 버그도 수정했습니다.
2. 작동 중인 floodfill peer들을 우선적으로 선택합니다. 코드는 이제 가능하다면 차단 목록에 있거나, 실패하거나, 30분 동안 응답이 없었던 peer들을 피합니다.

한 가지 장점은 I2P Site에 대한 첫 번째 연결이 더 빨라진다는 것입니다 (즉, leaseSet을 먼저 가져와야 하는 경우). 조회 타임아웃은 10초이므로, 다운된 피어에게 먼저 요청하지 않는다면 10초를 절약할 수 있습니다.

이러한 변경 사항들에는 익명성에 대한 영향이 있을 수도 있습니다. 예를 들어, floodfill store 코드에서는 차단목록에 있는 피어들이 회피되지 않는다는 주석이 있는데, 이는 피어가 “불량"할 수 있고 그 다음에 무슨 일이 일어나는지 볼 수 있기 때문입니다. 검색은 저장보다 훨씬 덜 취약합니다 - 빈도가 훨씬 적고, 노출되는 정보도 적습니다. 그래서 아마 우리는 이것에 대해 걱정할 필요가 없다고 생각할까요? 하지만 변경 사항을 조정하고 싶다면, “다운” 상태이거나 차단목록에 있는 피어에게 전송하는 것은 쉬울 것입니다. 단지 우리가 전송하는 2개의 일부로 계산하지 않으면 됩니다 (실제로 응답을 기대하지 않으므로).

floodfill 피어가 선택되는 곳이 여러 군데 있는데, 이 수정사항은 그 중 하나만 다룹니다 - 일반 피어가 [한 번에 2개씩] 검색하는 대상입니다. 더 나은 floodfill 선택이 구현되어야 할 다른 장소들:

1. 일반 peer가 저장하는 대상 [한 번에 1개] (무작위 - 타임아웃이 길기 때문에 자격 조건을 추가해야 함)
2. 일반 peer가 저장을 확인하기 위해 검색하는 대상 [한 번에 1개] (무작위 - 타임아웃이 길기 때문에 자격 조건을 추가해야 함)
3. floodfill peer가 실패한 검색에 대한 응답으로 전송하는 대상 (검색과 가장 가까운 3개)
4. floodfill peer가 플러딩하는 대상 (다른 모든 floodfill peer들)
5. NTCP 6시간마다 “속삭임"으로 전송되는 floodfill peer 목록 (다른 floodfill 개선사항으로 인해 더 이상 필요하지 않을 수 있음)

할 수 있고 해야 할 일들이 더 많이 있습니다:

• floodfill peer의 통합을 더 잘 평가하기 위해 “dbHistory” 통계 사용
• 응답하지 않는 floodfill peer에게 즉시 반응하기 위해 “dbHistory” 통계 사용
• 재시도에서 더 똑똑하게 동작 - 재시도는 FloodOnlySearchJob이 아닌 상위 레이어에서 처리되므로, 방금 시도한 ff peer를 의도적으로 건너뛰는 대신 다른 랜덤 정렬을 수행하고 다시 시도함
• 통합 통계를 더욱 개선
• netDb에서 단순한 floodfill 표시가 아닌 통합 통계를 실제로 사용
• 지연 시간 통계도 사용할까?
• 실패하는 floodfill peer 인식에 대한 더 많은 개선

최근 완료됨:

• [Release 0.6.3에서] 네트워크 분석을 기반으로 일부 비율의 class O peer들에 대해 floodfill 자동 opt-in 구현
• [Release 0.6.3에서] floodfill 트래픽을 줄이기 위해 netDb 항목 크기를 지속적으로 감소 - 현재 네트워크 모니터링에 필요한 최소 통계 수에 도달
• [Release 0.6.3에서] 제외할 floodfill peer들의 수동 목록 (router ident별 blocklists )
• [Release 0.6.3에서] 저장을 위한 더 나은 floodfill peer 선택: netDb가 오래되었거나, 최근 저장 실패가 있거나, 영구 차단된 peer들 회피
• [Release 0.6.4에서] RouterInfo 저장을 위해 이미 연결된 floodfill peer들을 선호하여, floodfill peer들에 대한 직접 연결 수 감소
• [Release 0.6.5에서] 더 이상 floodfill이 아닌 peer들이 쿼리에 응답하여 자신의 routerInfo를 전송, 이를 통해 쿼리를 수행하는 router가 해당 peer가 더 이상 floodfill이 아님을 알 수 있음
• [Release 0.6.5에서] 자동으로 floodfill이 되기 위한 요구사항의 추가 조정
• [Release 0.6.5에서] 빠른 floodfill들을 선호하기 위한 준비로 응답 시간 프로파일링 수정
• [Release 0.6.5에서] 차단 목록 기능 개선
• [Release 0.7에서] netDb 탐색 수정
• [Release 0.7에서] 기본적으로 차단 목록 기능을 활성화하고, 알려진 문제 발생자들을 차단
• [최근 릴리스의 여러 개선사항들, 지속적인 노력] 고대역폭 및 floodfill router들에 대한 리소스 요구사항 감소

긴 목록이지만, 많은 피어들이 floodfill 스위치를 켜고 끄거나 floodfill router인 척하는 것으로부터 DOS에 저항할 수 있는 네트워크를 구축하려면 그만큼의 작업이 필요합니다. floodfill router가 단 두 개뿐이었고, 둘 다 24시간 내내 가동되었을 때는 이런 문제가 전혀 없었습니다. 다시 말해, jrandom의 부재는 개선이 필요한 부분들을 우리에게 지적해주었습니다.

이러한 노력을 지원하기 위해, floodfill 피어에 대한 추가 프로필 데이터가 이제 (릴리스 0.6.1.33부터) router 콘솔의 “Profiles” 페이지에 표시됩니다. 이를 사용하여 floodfill 피어를 평가하는 데 적합한 데이터를 분석할 것입니다.

네트워크는 현재 상당히 복원력이 있지만, floodfill 피어들의 성능과 신뢰성을 측정하고 대응하는 알고리즘을 계속해서 개선할 것입니다. 현재로서는 악의적인 floodfill이나 floodfill DDOS의 잠재적 위협에 완전히 강화되어 있지는 않지만, 대부분의 인프라가 갖춰져 있으며 필요시 신속하게 대응할 수 있는 좋은 위치에 있습니다.