Previously, Xiaodan Tang wrote in qdn.public.qnxrtp.os:
All right. So many questions, let’s do it one by one.
Actually, the question was rhetorical. In a network of peers, you
cannot store globally unique information on a single node without
making it a global point of failure. The idea of a file in a
well-known place is about as far from fault-tolerant design as we can
get while staying with QNX. You (QSSL) battled this same problem with
nameloc in QNX4.
Andrew Thomas <> firstname.lastname@example.org> > wrote:
As far as other unique identifiers. What if the processes are on the
same node, and there is no ethernet card? If the processes are peers,
then who gives out the globally unique identifiers? Who stores the
files? Who serializes access so there are no races? I’m looking for
By “other unique identifiers”, I mean anything IS “fixed-length-globally-
unique” to your porcess. A file in a well-known place which contains
“Id FQNN” pair, all your process talk to a third party server to get
that identifier… Any way, but this is not what you like, right >
global uniqueness, and nid/pid/chid are supposed to be globally unique
on a QNET.
No, your “suppose” is wrong. Let’s confirm it again, nd(not nid)/pid/chid
IS NOT globally unique, it is only unique in one node. The only globally
unique thing IS the FQNN, and yes, it is not fixed length.
This is the point that we are ultimately coming to. In order for
process B to attach to process A, it must have the nd/pid/chid for A.
However, A cannot tell B its nd/pid/chid without knowing which node B
is on. A cannot tell the nd of B to C, even by FQNN (which is not
globally unique, see below).
There are server’s using the technic to gathering
“nd_of_me_on_his_machine/mypid/mychid”, pass it back to remote,
so remote could connect back. Proc, for example, doing this
all the time.
But this won’t work through a queue.
Can you explain more detail?
A queue, generally, hides the receiver from the sender. A sends
messages to B only through an agreed-upon mailbox at a third-party
location. A, B and the queue server can all be on different nodes. A
has no way to know which node B is on. Therefor
“nd_of_me_on_his_machine” is not generally knowable. Before you say
“gee that’s getting pretty hypothetical”, this is the case that
actually caused me to ask the question.
OK, so let’s say that nd is effectively safe. The question still
applies. How to transmit nid/pid/chid to identify A when the
node of B is not known.
I am not so sure of the question. You case 1) in your
orignal post can be done by:
A obtain A’s_nd_on_node_B/A’s pid/A’s chid, send it back to B;
A obtain A’s_nd_on_node_C/A’s pid/A’s chid, send it back to C;
The only “problem” is that the 2 messages are different, why is
this so important ?
I’m coming around to the idea that this is the least of many evils,
and now just have to figure out whether B’s FQNN can be known by A in
all cases. This still does not work in the case of a queue, where A
doesn’t know which node B is on. The question is whether I can live
with that restriction.
If it will make the problem easier, let’s just look at two cases:
MsgSend() and queued messages. Forget about sockets for
the time being. I think that if we can produce a solution for
transmitting a message via a queue where the receiver’s node
is not known, then that will be good enough.
I am a little bit confusing. When you say “queue”, you are talking
I’m talking about the general concept of a message sent via an
agreed-upon third party.
In case of MsgSend(), you need to ConnectAttach() first, which
request a (nd, pid, chid). If you don’t know the nd of B, then
you call netmgr_strtond() to get the nd.
If I need to call netmgr_strtond() every time I want to send a message
to B, that is really expensive. If I want to find
“my_node_according_to_him” for every message, this is intolerably
expensive. Remember that I’m looking for a way that B can send a
message back to A based on the information that A sent.
Or are you saying you don’t even know the name of node you want
Currently, if you don’t know the node’s name you want to talk
to, you can’t talk to them.
Wrong. I can use a queue. In the more general case, I can use any
non-MsgSend() mechanism to transmit a message, and it will have the
same properties in this regard as a queue.
You also didn’t answer the question of whether the FQNN
as a string is actually usable, given that two nodes may have
different ideas of the MAC-to-name mapping.
Since the FQNN is “global unique”, this will fail. ie,
if A knows C as “foo”, but B knows C as “bar”, and A send a
message to B say “talking to the pid/chid on foo”, B will
return error say “I don’t know ‘foo’”.
(there is a way in QNET to “alias” different name to same node,
but let’s not get in there first).
In the above case, who have the knowladge that “foo” is “bar” ?
Nobody. That was my question. It seems that FQNN is not sufficient
to for A to identify B to C. The frustrating thing here is that if
you stick to open() calls and resource managers, everything is fine.
I just happen to be trying to color outside the rather narrow lines
that seem to have been painted by the nd/pid/chid implementation.
When all is said and done, I think the answer here is:
A must always know B’s node FQNN in order for A to identify itself
to B. There is no way for A to use the same information to
identify itself to two different processes unless it does so using
its FQNN. This is annoying and won’t work in the case where A does
not know which node B is on. It is certainly a step backward from
Both A and B must be willing to accept a finite chance that if they
attempt to attach a connection to one another using nd/pid/chid,
that connection might in fact go to a completely different process
on a completely different node (the nd and/or pid are stale). The
chance seems remote, but it hurts the mathie in me. It may
actually be lower than the equivalent chance of this happening with
QNX4 because the PID space is larger in QNX6.
All nodes on the network have to agree on the FQNNs of all other
nodes, otherwise the whole nd/pid/chid scheme appears to fall
apart. This appears to be a real step-to-the-left relative to the
experiences of TCP/IP developers, where a name is just a
convenience to refer to the globally unique identifier, and the
globally unique identifier is sacred. What we appear to have
concluded is that QNET has no globally unique identifiers. (And
no, MAC address isn’t it either. Not all machines have ethernet
cards. I’ve read the posts saying that QNET is not tied to the
When I started this thread, what I was really looking for is the
implementation limitations of QNET so I knew how to go about solving
my problems. Do the above points accurately describe QNET?