Questions about new duniter nodes

Support Duniter-v1
1

Hi,

I have few questions about running a brand new Duniter node.

First,when you have to add a new node, what is the best usage about the choice of “–remoteh host.peer.dunter.org” ?
I guess if everybody use the same “root” this one should be overloaded very quickly, especially if running initial sync. Perhaps, we have to create some rules about that no ?

After that, i have not found the way to “publish” identity of a new node. When you setup duniter node via “wizard key”, you’re not asked about UID, the only thing you can get is your public key:

2016-08-22T22:40:57+00:00 - info: Node version: 0.30.4
2016-08-22T22:40:57+00:00 - info: Node pubkey: HPL4i16UsELW6XJaZDv9wvEMaX8kSSeC3cPug9FmbutV

So, how to do a publication of this information to be certified ? I have tried to search this publickey without success…
Perhaps is there a first “message” to create, like “I want to become a member” ?

And a last one, i use a lot of “virtual” servers, so they are very often NATed… is there a way to setup “external” IP on a Duniter node ? For now, i have this warning:

2016-08-22T22:40:57+00:00 - warn: No UPnP gateway found: your node won't be reachable from the Internet. Use --noupnp option to avoid this message.

In fact this node is reachable from Internet, but i need to “push” some were the good IP@…

Thanks in advance for any help, and be indulgent, i’m new in this project :wink:

2

Hello,

You’ll find necessary informations in this article (level 3) https://github.com/duniter/duniter/blob/master/doc/contribute-french.md#niveau-iii--maîtriser-les-commandes-usuelles

3

Unfortunately, i have already checked this documentation about these questions without success.

4

The wizard network parameters should help you configure remote endpoints without any need to use upnp.

For example :

[Intranet : Your PC] <—> Your BOX [nat] <----> Internet

The local endpoint configuration would be your intranet IP. Probably 192.168.xxx…
The remote endpoint configuration would be your BOX IP. This will give you this information : http://www.mon-ip.com/

The duniter port should be routed from your box to the computer running Duniter.

5

Thanks, in fact i was afraid because the node i was running for hours was still not visible in network tab. So i was guessing there is a need to publish my public IP@ (as returned by monip.org). But it’s much more simple :wink:
In my case (virtual server on internet), there is nothing to do :

[ Internet ]
       |               fowarded port
       v                 9330
[ physical server ] <-> [ virtual machine ] 
163.172.130.151          10.x.x.x

With this configuration, it’s ok :

$ node ./bin/duniter config --port 9330 --ipv4 10.xx.xx.xx --remoteh 163.172.130.151 --remotep 9330

Now this server should be visible in network tab… And it seems that peers use automaticaly my public IP to connect back. The protocol is well done, sorry for noise.

Now, next step, i’m trying to put a certified account on this node :

2016-08-23T19:30:41+00:00 - warn: Public key of the peer has changed from HPL4i16UsELW6XJaZDv9wvEMaX8kSSeC3cPug9FmbutV to 2VAxjr8QoJtSzhE7APno4AkR2RAQNySpNNvDzMgPotSF

Just hoping it will not raise this error for ever… :wink:

Otherwise, the remaining question was about the node used for initial sync… In the same way, when i have tried, cgeek.fr was really overloaded… so i was asking to myself if a policy need to be created to avoid this.
Something like :

Do not sync from “root” (cgeek.fr) node, prefer use “pool.duniter.org” !

Remain to create a dns record on this name with plural IP. More, if this list will be dynamic, it can be awsome !
But perhaps, there is no need for now, initial syncing are rare…

1 Like
6

OK, several things to say :slight_smile: but first, thanks for your tests and questions.

Their is a first confusion here: --remoteh option is an information for external nodes to reach yours, using a DNS name. For example, if you use this option like:

$ duniter config --remoteh dune_02.modulix.net

Then you simply say that your node can be accessed publicly using dune_02.modulix.net DNS address.

But you could also specify directly an IP, like:

$ duniter config --remote4 163.172.172.197

Or even combine the two:

$ duniter config --remote4 163.172.172.197 --remoteh dune_02.modulix.net

This way, you give 2 options to access your node publicly. You also have a third --remote6 option to give an IPv6 address.

But these options have nothing to do with initial synchronization: it is only public declaration on how to access your node.

Also, if you use IPv4 information for --remoteh option instead of a DNS name, this raises errors in our nodes. It will likely work and we will be able to contact your node, but that’s not what is expected.

You do not have to publish your identity: the simple fact to share the same key as your identity key with your node make it able to act as if the node was you. That’s why your node only need your key: it will be able to find alone what is your UID, because this is publicly written in the blockchain (well, once you are a member :slight_smile: before that, it is just a key, no identity is linked to it).

Yes this is clearly a good idea, however I don’t know how to technically do it.

7

When a node respond to a sync request, if it is overloaded by an already running sync, may be it can respond instead with a list of trusted peers to redirect to…?

8

The problem is: the node don’t actually know it is overloaded … it is answering, but a timeout occurs.