node doesn't know it's id

[PavelPolyakov]

Hi,

I have the next question. When some node connects to the network, the other node can identify it by id and the hostname. Like this (console log): node-app A new node has been added. {"isMaster":true,"isMasterEligible":true,"weight":-0.1450726893915,"address":"172.28.128.21","lastSeen":1450726903761,"hostName":"C","port":22222,"id":"99cbcfef-4d0f-435e-afab-495f69ac35b0"} +716ms

However, I haven't found the place inside the node itself, which contains the same id.

I found the:

d.broadcast.instanceUuid
d.broadcast.processUuid

However, these are not the ids which other nodes are using to identify the newly connected node.

Why I need this? I want to include this information to the channel message, so the node would know that this message was addressed to it.

Any thoughts if it is possible? Or what is the expected behaviour? I don't want to identify the nodes by the hostnames, because those are not uniq.

Regards,

[PavelPolyakov]

My current workaround is to place the uuid to advertisement object.

this.d.advertise({uuid: this.uuid});

Then it would be accessible as d.me.advertisement.uuid.

But I still think, that id should be known by the node itself as well.

[wankdanker]

Hi @PavelPolyakov,

I'm not entirely sure I grasp what you experiencing. The expected behavior that the id of a node as seen remotely is the d.broadcast.instanceUuid. I just verified this with a quick test:

Consider Two Nodes, A and B

A

$ node basic-argv.js --port=8943
d.me: { isMaster: false,
  isMasterEligible: true,
  weight: -0.1450729827777,
  address: '127.0.0.1' }
instanceUuid 393f23aa-fabc-486e-b486-97beb9ed134c
processUuid 2db2a48d-e0fd-44c8-bc69-4927f86eef23

B

$ node basic-argv.js --port=8943
d.me: { isMaster: false,
  isMasterEligible: true,
  weight: -0.1450729842436,
  address: '127.0.0.1' }
instanceUuid 6ca88add-b3c9-4ca3-ad49-ef0e2e73e7c5
processUuid 910d89e9-564c-423f-bc23-f4aeacde1f88

After discovery

A

New node added to the network.
{ isMaster: false,
  isMasterEligible: true,
  weight: -0.1450729842436,
  address: '192.168.100.17',
  lastSeen: 1450729843445,
  hostName: 'computer',
  port: 8943,
  id: '6ca88add-b3c9-4ca3-ad49-ef0e2e73e7c5' }

B

New node added to the network.
{ isMaster: true,
  isMasterEligible: true,
  weight: -0.1450729827777,
  address: '192.168.100.17',
  lastSeen: 1450729842795,
  hostName: 'computer',
  port: 8943,
  id: '393f23aa-fabc-486e-b486-97beb9ed134c' }

So, the new node seen by A has an id of 6ca88add-b3c9-4ca3-ad49-ef0e2e73e7c5 which is the instanceUuid of B.

And the new node seen by B has an id of 393f23aa-fabc-486e-b486-97beb9ed134c which is the instanceUuid of A.

So, that all seems to be working as I would expect. Can you provide an example counter to this?

[PavelPolyakov]

@wankdanker

Ok, indeed you are right. Just checked, it is instanceUuid.

Probably my first quick test was more "quick" than "test".

Thanks.

Could you tell me if I can freely do something like this (right after new Discover()):

d.broadcast.instanceUuid = 'my pretty uuid';

as long as it's unique.

or this variable is kinda private?

Regards,

[wankdanker]

Cool.

You can do that. You would just want to make sure that it is set before the node sends out its first hello packet.

I've tried to make this module as flexible as possible. So, give it a shot and see how it goes.

[PavelPolyakov]

@wankdanker Looks like working, thanks!

I'm currently developing the proof of concept of the auto discoverable cluster, using node-discover and etcd. Here it is: https://github.com/PavelPolyakov/etcd-test . Going to describe it in article soon.

Check if you want to.

node-discover app is here: https://github.com/PavelPolyakov/etcd-test/tree/master/node-app-vagrant

The only downside which I see right now, is a need to reinit the Discover each on all the nodes as soon as new node is shown. But that's a topic of the different discussion :) node-discover is great library!