Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4029 closed Bug (fixed)

Dht bootstrap nodes dodgy.

Reported by: jch Owned by: John Clay
Priority: Normal Milestone: None Set
Component: Website Version: 2.20
Severity: Normal Keywords:
Cc:

Description

91.121.60.42 and 2001:41d0:1:aa81:2::1 are no longer acting as DHT bootstrap nodes.

--jch

Change History (5)

comment:1 Changed 11 years ago by jordan

20:05:43 <@titer> both nodes are running the same patched dht-example now
20:06:12 <+klapaucjusz> I'm not seeing any packet loss any more :-)

Should this ticket be closed?

comment:2 Changed 11 years ago by jch

  • Resolution set to fixed
  • Status changed from new to closed

comment:3 Changed 11 years ago by User294

I can suggest this to be a list of "known stable" nodes with more than 10-20 peers or so. Having single point of failure is a bad idea, especially if we remember that DHT designed to be fault-tolerant and should not rely on trackers, etc.

comment:4 Changed 11 years ago by jch

I can suggest this to be a list of "known stable" nodes with more than 10-20 peers or so.

We don't want to rely on nodes that are not controlled by us.

Having single point of failure is a bad idea

We don't have a single point of failure. We use multiple techniques for bootstrapping the DHT:

(1) we bootstrap from nodes saved to disk;

(2) we bootstrap opportunistically from nodes learnt from a tracker;

(3) we bootstrap the v6 DHT from the v4 DHT, and vice versa;

(4) we bootstrap from dht.transmissionbt.com, which consists of two distinct node at two distincts ISPs.

The problem here is that currently the v6 DHT is too small to make (2) and (3) effective, but at the same time it has become large enough to overwhelm the buggy version of (4). We have now fixed the issues with (4), which is able to deal with the increasing load.

(2) and (3) will become effective in due time, hopefully way before (4) is overwhelmed again.

--jch

comment:5 Changed 11 years ago by User294

We don't want to rely on nodes that are not controlled by us.

But why? Are there any harm/disadvantages in doing so? Or any other reasons? After all, your nodes are depending on other nodes anyway, and they will supply them anyway. So I do not see major difference if you will supply just 2 nodes and then they will supply "foreign" nodes, or if you will supply your 2 your nodes + some "foreign" nodes immediately. I can see difference in reliability but can't see major difference in resulting buckets state, etc. Am I missing something?

We don't have a single point of failure. We use multiple techniques for bootstrapping the DHT:

Somewhat right. And thank you very much, btw. Now I can bootstrap in much more configuration - this made it possible to use T on several more machines :). But let's look closer?

(1) we bootstrap from nodes saved to disk;

Does not exists on 1st startup, unfortunately. All other startups are much easier for sure, thanks to this file. But as for me I would really prefer to have similar list at 1st startup as well (to make sure it succeeds). Because if 1st bootstrap fails, there is no subsequent ones, obviously (chicken and egg problem).

(2) we bootstrap opportunistically from nodes learnt from a tracker;

Yes, but most trackers I recently encountered were so unreliable these days that I would not rely on them at all. Most of them are half-working to say the least.

(3) we bootstrap the v6 DHT from the v4 DHT, and vice versa;

That's fine, as long as things already running. The problem will be when they aren't.

(4) we bootstrap from dht.transmissionbt.com, which consists of two distinct node at two distincts ISPs.

But wouldn't, say, single DNS failure stop all this from working? And you told you had problems. I always though DHT is a way to do lookups in a distributed manner, without relying on central things. That what makes dht robust.

P.S. you also forgot (5) - you've left a method to manually bootstrap DHT. It sometimes really saves me, and even if it's rarely needed, it still can save a day sometimes :). Btw maybe you should document this somewhere? I think it's ok for Wiki but it not looks like if I can create/modify pages. But I think others may sometimes want to learn how to use this "backup parachute".

Note: See TracTickets for help on using tickets.