Preferred mechanism to select node ids for session?

[twhittock]

Since NORM_NODE_ANY doesn't work for receivers (even the examples have a hardcoded receiver node id)

What mechanism should users use to create node ids for joining a session?

It seems like users need to write their own negotiation protocol to decide on node ids before they are even able to join the NORM session?

[twhittock]

In the absence of any other obvious choice, rather than negotiating a node id, I've personally decided to use the hash of (unique pointer address, PID, hostname) as the node id.

This should hopefully be sufficiently unique, assuming there are no hash collisions....

It would still be good to understand why this is left up to the caller, and what the authors consider to be a good mechanism for choosing the node id, though...

[bebopagogo]

Hi @twhittock - Sorry for the slow response here; my work schedule has been a bit consuming.

What NormNodeId assignment are you seeing when you call NormCreateSession() with NORM_NODE_ANY and then call NormGetLocalNodeId() to see what was assigned? Passing in the NORM_NODE_ANY (NORM_NODE_NONE) value should cause the NORM code to get a local IP address and use that as the NormNodeId as a form of automatically picking a unique node id. However, there cases where this doesn't work correctly (e.g., some VM environments or testing multiple processes on the same machine). In that case, I usually manually assign node ids for testing purposes. In some of our deployed systems that use NORM, they have other unique identifiers that are used as NormNormIds.

One of the improvements I would like to eventually make with the NORM protocol specification is to have some other options for NORM node identification (e.g., address/port binding by itself) instead of the administratively configured NormNodeId. The rationale for use of a separate identifier was "inspired" by some of the RTP (realtime protocol) use cases where, due to bridging through various telecon systems etc, it was deemed necessary to have SSRC ID as an identifier distinct from IP addressing for multicast purposes. However, this is certainly inconvenient and I think there are many uses cases that would be well-served to use the socket address binding info as the needed unique identifier.

Meanwhile, your approach to pick a random number will small collision probability isn't horrible, but I'm never fond of having to do that. Would the approach that is supposed to work, auto NormNodeId assignment based on IP address, work for your use case?

[twhittock]

Hi, thanks for the response! Yes I was doing the initial testing on a local machine, so the NORM_NODE_ANY mechanism wouldn't work in that case, and seeing it wasn't used in the examples either, I made the assumption it didn't work at all, so didn't revisit it when moving to multiple systems - that's my mistake!

Sadly, in my use case having multiple nodes on the same system, while unusual, isn't unheard of, so even in production, I won't be able to use NORM_NODE_ANY as it currently exists.

I like the idea of simply using the address & port binding as the final identifier of the node - it keeps the protocol simpler and reduces the barrier to get up and running.

I will look around our system to see if I can dig up another 32 bit identifier which could be guaranteed unique - that's a good idea, and I agree about the hash technique feeling bad, but writing a node id negotiation protocol in order to start the actual communication channel seems like such a large barrier to entry, and extra complexity.

Thanks for such a thorough answer!

[bebopagogo]

Yes ... I have been in that same situation with respect to node ids. One trick I have done is use an IP address combined with a process id to give me a partial guarantee of uniqueness when there is a mix of instances on different machines (but perhaps on a common subnet so use some of the IP address (e.g., lower 16 bits as the the upper 16 bits of the NormNodeId and the process id as the lower 16 bits)