IPC with nid,pid,chid - what nid?

Alain_Bonnefoy2 · February 26, 2001, 8:08am

<!doctype html public “-//w3c//dtd html 4.0 transitional//en”>

Xiaodan Tang a écrit :

Chris give a good point that we seems didn't make it clear
in previos post.
Even though, keep a nd is not a good thing, keep a coid is totally
safe.

Once you established a connection (ConnectAttach()), that connection
will always valid, until you ConnectDetach(). If the node you are
talking to, is gone (and even comming back later), next time you
using the connection, you will got error.

-xtang

Chris McKillop <> wrote:
> Andrew Thomas <> wrote:

> Hey Andrew...

>> 1) 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
>>    QNX4.
>>

> Really? I don't think so at all. Instead of having to map a node#
> to a specific MAC address and keeping that constant on all machines you
> only need to keep a mapping of a name to an IP address in /etc/hosts
> and you can change one machine in the system without having to touch
> all the other machines. And since you control the entries in /etc/hosts
> you can force the names to a fixed length.

> Here is something I am not really clear on in all your postings. You are
> worried that getting the nd from the name will cost you too much if you have
> to do it everytime you want to send a message. Are you tearing down the
> connection between every message? That is the only time you need you need
> to know the nd, once you have connection established you can keep using that
> until it becomes invalid and then, and only then, do you have to lookup
> the nd of the remote node again. This is very different from QNX4 in which
> the connection is tied to the PID. And if you are tearing down the connection
> between every message then the cost of looking up the nd is gonna be 0
> relative to the cost of setting up the connection over the network. :wink: Maybe
> I am missing something in what you said....

>     chris

> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>                     "The faster I go, the behinder I get."
>   Chris McKillop                             -- Lewis Carroll --
>   Software Engineer, QSSL
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

It's maybe easier to find a node in qrtp than in qnx4. The problem, not yet solved in qrtp is, how to find a service?
And it's, I think, the big difference. You gave us an easier way to find a node, as you explain, we no more need to establish a relationship, on all nodes, between mac address and node ID, but in fact, knowing a node is not really important.
When client wants a service, it just wants to ask for the service name, knowing where this service run and how to connect to it, is your problem, not ours. From this point of view, qrtp is well a step backward from qrtp!
Since it's not yet possible to use global names through qnet!

Alain.

Dean_Douthat1 · February 26, 2001, 3:06pm

Andrew Thomas wrote:

Previously, William M. Derby Jr. wrote in qdn.public.qnxrtp.os:
I’ve been dealing with the same sort of problems on my system as I
port to Neutrino and this is what I came up with – perhaps it will be
somewhat useful. I too did not want every task in my system to be a
resource manager and hence run at root privaleges. The scheme I came
up with is to create 1 resource manager called namesrvr which handles
the filesystem in say /dev/mynames. Processes register the connection
information by creating a “file” in the namesrvr and writing the
nid:pid:chid of the connection for the process into the file. The file
handle is not closed until the program detaches the connecton or
terminates - which automatically closes the file. Close files cease to
exist or the contents are reset to -1> > -1. (I haven’t fully settled
on this yet) If you run a namesrvr on each machine, you can search
for the name of the file on all the /net/XXXX/dev/mynames. Iin this
way you will also be able to extract the name of node which sould
allow for correction of the local node NID… ( i.e. the entry in /net
will be your local name)

We have a similar thing here. We are planning to make the name server
update other name servers on the network automatically as well. We
want to avoid the case where a program is obliged to do network
messaging to look up a name.

Since you only register on your machine, all you need to worry about
is the uniqueness of the local name - remote name will always have
the node name is a qualifier to separate duplicates. As far as
sending the name - you could register the name for the connection as
“nd_pid_chid” send the tuple in you message and then search for it
in the net directory. You could additionally add the MAC address of
your card (one would do) to the registered name and send that as
well… So maybe you register “MAC_pid_chid” as your name and pass
them numerically as part of your message… The size is fixed and
relatively small and generating the filename to search for is
trivial…

The trouble is that in nd_pid_chid, nd is not useful. It will
always be zero to the process that registers the name. So names are
only unique to pid_chid. You need to store the FQNN on your
nameserver as well. MAC address may or may not exist.

In this model, all client programs simply need to have read
permission of the created files in /dev/mynames… I do not plan any
fancy permission scheme, but it certainly be possible. This model
also makes it really easy to retain the QNX4 name_locate
functionality with set of wrapper functions… The reason for the
resmgr at all is to automatically reap stale resgistrations…

Would something like this work for you?

It will, with some modifications. > > We also store a queue name and a
domain, and perform the name search with ioctl (for speed) as well as
allowing file system reads. It reduces the problems a fair bit, but
does not eliminate them. For example, I can screw up our name server
by running the name server on one machine and then creating a prefix
link from the other machine to its /dev/nserve directory. Now there
are two different nodes sharing the same name server and some
assumptions we made become false.

I wonder how many more people are writing name servers?

Cheers,
Andrew

Andrew:

As you may remember, the distributed nameserver database synchronization
problem was stated by Dan D. to be a difficult, perhaps NP-complete problem
with lots of race conditions and time windows for corruptions. I would hope
that there are NOT a bunch of people writing nameservers. This sounds like
something that should be developed “centrally”, not reinvented in
multiplicity. Perhaps QSSL sees this as a needed part of QRTP. Dan? Or is
this a candidate for an open-source project?

Andrew_Thomas1 · February 27, 2001, 9:44pm

Previously, Chris McKillop wrote in qdn.public.qnxrtp.os:

Andrew Thomas <> Andrew@cogent.ca> > wrote:

Hey Andrew…

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
QNX4.

Really? I don’t think so at all. Instead of having to map a node#
to a specific MAC address and keeping that constant on all machines
you only need to keep a mapping of a name to an IP address in
/etc/hosts and you can change one machine in the system without
having to touch all the other machines. And since you control the
entries in /etc/hosts you can force the names to a fixed length.

Limiting names in /etc/hosts is not the first choice in a solution.
People will always exceed any artificial name length limit that we
apply, unless we make the name length so long that it swamps the size
of the rest of the message payload and degrades message passing
performance.

Here is something I am not really clear on in all your postings.
You are worried that getting the nd from the name will cost you too
much if you have to do it everytime you want to send a message. Are
you tearing down the connection between every message?

The connection may never be established. Two processes can
communicate for the entire session through non-MsgSend mechanisms. I
am attempting to create a small message header that can be efficiently
transmitted with every message that will serve 2 purposes:

identify the originator of the message uniquely, and
give sufficient information that the receiver could open a
connection back to the sender if necessary.

Messages are not necessarily sent via MsgSend, and are not necessarily
synchronous. In my case, there is no expectation that there exists a
connection in either direction during the “conversation” between
processes. There is also no requirement that a communication channel
be bi-directional. Queues are uni-directional, as can be sockets,
fifos and pipes. I think you have formed the mistaken impression that
I am looking for a way to negotiate a connection initially (which is
in itself a problem with QNX6), but the truth is I am looking for an
identifying payload that meets the two criteria above that can be
transmitted with every message.

One of my underlying goals is to abstract the communication mechanism
so that the program (or programmer) can choose whichever communication
mechanism he likes for the forward messaging, and still leave the
option open to the receiver to use MsgSend on the back connection.

The other big problem I am trying to solve is one of identification.
If a process gets 2 messages via a queue, how can it tell whether the
messages originated from the same source or not? What if one message
comes via a queue, and the other via a Connection? This is the
uniqueness problem.

In QNX4, both problems were solved simultaneously with (nid,pid)
pairs.

And if you are tearing down the connection between
every message then the cost of looking up the nd is gonna be 0
relative to the cost of setting up the connection over the
network. > > Maybe I am missing something in what you said…

No, you’re not really missing something. I didn’t spell that part
out. There may or may not ever be a connection. Obviously if a
process creates a connection, then it will be used until it is closed
or invalidated.

Consider this case:

[postulate: there exists a networked queue server]

Process A offers a data sharing service. B somehow figures out the
queue name of A, and transmits messages asynchronously to A. A wants
to determine which of the 100 processes it has connections on has sent
the queue message. It needs an identifier in the body of the queue
message to determine that. If this is a queue message from a
previously unconnected process, A wants to open a connection to that
process and add it to the list. Every single message that arrives via
a queue must be tagged with a unique identifier of the sender in order
for this to work. That identifier must be 1) node independent - B
doesn’t know what node A is on, 2) small - to minimize bandwidth
usage, and 3) fixed length - to minimize parsing effort.

I’m trying really hard to avoid synchronous (and I would say out of
band) negotiation between processes to have them know each other’s
identity because this offers the opportunity for deadlock cases hidden
behind innocent API functions. It also complicates both the API and
the protocol that the API is attempting to offer.

Cheers,
Andrew

Andrew_Thomas1 · February 27, 2001, 10:00pm

Previously, Xiaodan Tang wrote in qdn.public.qnxrtp.os:

OK, I start to understand what you really want >

Andrew Thomas <> Andrew@cogent.ca> > wrote:
Previously, Xiaodan Tang wrote in qdn.public.qnxrtp.os:
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.

Well, what I mean “talk” is meant ConnectAttach() and MsgSend().

Now, if you are talking about “non-MsgSend() mechanism”, you
can of cause send out “whoever receive this message, send me
back your name, I will send you a nd/pid/chid to connect me”
on this “non-MsgSend() mechanism”, does it?

Not all communication channels are bi-directional. I can only send a
“whoever receives this message, send me back your name” message on a
queue if I have a way to identify myself uniquely, which is the crux
of the problem. The added complexity is that I want this identity to
be small, unique, fixed-length and receiver-node-independent.

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.

We take the above case is a “mis-configed” network.
If C have 10.1 and 11.1, A knows C as 10.1, and B knows C as 11.1,
how can A ask B to connect C ?

That’s backward. If C thinks that 10.1 is Alpha, and B thinks that
10.1 is Kappa, then B sending to Kappa and C sending to Alpha both
work just fine. With IP, you identify yourself by IP address, not
the hostname, since a correctly configured IP network does not
require that all machines agree on the hostnames. IP addresses are
unique and immutable.

So, a correctly configured IP network will cause QNET to fail. Yes,
it’s a stupid configuration, but it is not wrong, and it will function
just fine in the {TCP,UDP} world.

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
QNX4.

“A must know B to identify itself (using nd/pid/chid) to B”.

“A could broadcast (A’s FQNN/pid/chid) so whoever receive the
message, could connect back to A”, I don’t know why you claim it
won’t work.

I wasn’t aware of any broadcast mechanism in QNET, and you are not
seriously suggesting that constant broadcast is a good way for
cooperating machines to identify themselves? I remember when ruptime
and rwho were thrown out of town, and they were on 11-minute timers.

If A don’t which node B is on, A can not use MsgSend() mechanism
to “talk to” B. If A some how, could using some other way to
transfer messages to B, A could either ask B’s FQNN (so A could
send back nd/pid/chid), or A could send B A’s FQNN (to let b
connect back)

This is an answer if we are looking for an esoteric way to initially
establish a connection. I want a unique identifier that can ride in
the header of every message transferred, even if that message is not
delivered through MsgSend.

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
physical layer).

The FQNN IS (must be) globally unique. If it is not, (you have 2
nodes have the same name for example) QNET will not properly
functional.

Again, you are ignoring the perfectly legal case (in TCP/IP anyway)
where 2 nodes have different names for a third node. This
configuration is common. Since QNET uses the /etc/hosts and DNS for
some lookup, you can believe that this case will happen.

Oh, the “global name” service (name_*) is implemented into QNET
(internally). So a client could ask a service, without knowing
which node the service is on. (kind of like your name server in
your another post).

We wrote our own name server for QNX4 as well. The nameloc does not
provide enough information, and does not offer user-defined fields
that can be attached to the names. The name_* functions in QNX6
appear to have this same deficiency. Above all, they make the
assumption that all the caller really wants is a connection ID, which
is not true in my case.

Cheers,
Andrew

Andrew_Thomas1 · February 27, 2001, 11:45pm

Previously, Dean Douthat wrote in qdn.public.qnxrtp.os:

Andrew:

As you may remember, the distributed nameserver database
synchronization problem was stated by Dan D. to be a difficult,
perhaps NP-complete problem with lots of race conditions and time
windows for corruptions.

I don’t actually think that is true for all definitions of the
problem. (A little aside - you have to define the problem a little
more rigorously to even take a stab at whether it is NP-complete). In
my non-rigorous world, it should be possible to create a distributed
name server that runs one copy on each of N nodes that generates O(N)
messages every time a name is created or destroyed, that consists of
O(N) connections among name servers, and that generates O(N) messages
every time a name server starts or stops on any node. (Another aside

to do this you would have to have a way to uniquely identify all
nodes in such a way that the sorting order of the identifiers was
node-independent.)

I would hope that there are NOT a bunch of people writing
nameservers. This sounds like something that should be developed
“centrally”, not reinvented in multiplicity. Perhaps QSSL sees this
as a needed part of QRTP. Dan? Or is this a candidate for an
open-source project?

The real problem is that everybody has a different definition of what
a name server should be. I would like to see a name server that can:

make name/node/pid/chid/queue/domain/user_data available for a
process,
allow more than one name/queue/domain per node/pid/chid,
run exactly one copy per machine,
generate a notification to all other processes with attached names
whenever any name is created or destroyed, on a network-wide basis,
discover when a node crashes or is removed from the network, and
remove all names associated with that node, generating
notifications for all such names,
discover when a node returns to the network, and resynchronize all
names from all nodes,
exhibit O(N) complexity,

never block on a synchronous send,

allow multiple nodes to share a single instance of the name server.

I do not care about:

~10) force all names on the network to be unique.

A lot of people want their name server to enforce 10), which is
impossible in the general case. It seems to be possible in O(N) time
on a stable network, but in the end it’s not a particularly useful
goal. I would not want to pay the performance penalty to get it.

Many people do not care about, or want variations on, points 1,3,4,5
and 8 above.

The QNX4 nameloc, and the QNX6 name_* functions do not meet most of my
requirements from a name server. They make the assumption that the
user plans to use the name to create a connection, and do not a) make
the underlying information available without first constructing that
connection, and b) do not carry the extra payload that we require.

We are planning to make our name server available in binary form with
a free-for-non-commercial-use license shortly. It doesn’t meet all of
our requirements right now, but it does meet some. At that point we
will have a concrete implementation that may act as a starting point
from which to expand. We would certainly welcome input.

Cheers,
Andrew

Chris_McKillop1 · February 28, 2001, 9:46am

Andrew Thomas <Andrew@cogent.ca> wrote:

Really? I don’t think so at all. Instead of having to map a node#
to a specific MAC address and keeping that constant on all machines
you only need to keep a mapping of a name to an IP address in
/etc/hosts and you can change one machine in the system without
having to touch all the other machines. And since you control the
entries in /etc/hosts you can force the names to a fixed length.

Limiting names in /etc/hosts is not the first choice in a solution.
People will always exceed any artificial name length limit that we
apply, unless we make the name length so long that it swamps the size
of the rest of the message payload and degrades message passing
performance.

Okay, then use IP addresses as the fixed value. Fact is that under
QNX4 the only reason why you could have a nid/pid pair is the netmap
file. Now, instead of relying on the MAC layer to id a node we use the
IP layer, so now you have an ip/pid pair. Since the IP address can be
used to make socket connections and can also be used to generate a connection
for MsgSend() I think this provides you with the uniquness you and the fixed
length record that you require. You can even be forward thinking and make the
header size big enough for an IPv6 address.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Andrew_Thomas1 · February 28, 2001, 11:41am

Previously, Chris McKillop wrote in qdn.public.qnxrtp.os:

Andrew Thomas <> Andrew@cogent.ca> > wrote:

Really? I don’t think so at all. Instead of having to map a node#
to a specific MAC address and keeping that constant on all machines
you only need to keep a mapping of a name to an IP address in
/etc/hosts and you can change one machine in the system without
having to touch all the other machines. And since you control the
entries in /etc/hosts you can force the names to a fixed length.

Limiting names in /etc/hosts is not the first choice in a solution.
People will always exceed any artificial name length limit that we
apply, unless we make the name length so long that it swamps the size
of the rest of the message payload and degrades message passing
performance.

Okay, then use IP addresses as the fixed value. Fact is that under
QNX4 the only reason why you could have a nid/pid pair is the netmap
file. Now, instead of relying on the MAC layer to id a node we use
the IP layer, so now you have an ip/pid pair. Since the IP address
can be used to make socket connections and can also be used to
generate a connection for MsgSend() I think this provides you with
the uniquness you and the fixed length record that you require. You
can even be forward thinking and make the header size big enough for
an IPv6 address. >

Some things come to mind:

IP addresses are not unique on a machine. A single computer can
have multiple IP addresses. This is true for any IP network,
admittedly. It still poses a uniqueness problem.
I was not aware that QNET requires an IP address. What happens if
there is no IP network involved, or is IP an absolute prerequisite
for QNET? What about the case where both processes are on the same
node? How about ArcNet or Token Ring? If an IP address is
guaranteed to exist for all installations of QNET, how do I map an
IP address <—> nd? Or, I guess the real question is: How do I
open a connection given (IP address, pid, chid)?

If there is a good answer to 2), then this is a Good Idea. If IP
address is in fact sufficient to identify a node, then why do you have
node descriptors at all? Isn’t (IP addr,pid,chid) a better mechanism
than (nd,pid,chid) in all cases?

Cheers,
Andrew

Andrew_Thomas1 · February 28, 2001, 11:50am

Previously, Michael J. Ferrador wrote in qdn.public.qnxrtp.os:

I’m new to this correctness / mathmatically provable thing BUT…

assuming RTC’s in all nodes

how about Machine ID + Boot Time + PID … etc ?

Generalizing that a little, you can produce a hash of hopefully unique
information into a hopefully unique hash that can be used to identify
a machine, but:

it assumes the existance of the hash inputs on all machines. MAC
address, CPU ID, number of PCI slots, CPU speed, RAM size, etc. are
all candidates, but is there anything that works on all machines,
whether PC/104, Compact PCI, home-grown embedded? You can quickly
eliminate MAC address and CPU ID, and after that, the candidates
seem like pretty weak differentiators.
hashes have a finite probability of colliding. This may be
detectable, but the effort to correct it once detected is
prohibitive.
Schemes relying on boot time, system sizing, CPU cycles, and other
transients (yes, you can add new memory to a machine), only
generate uniqueness for a single reboot. This may not be a
problem, but it certainly is not persistent.
The hash gives you no useful information about how to open a
connection back to the machine. You need a global hash <–> FQNN
mapping service. Such a service is the same problem as the
uniqueness problem in a name server, which in the general case is
provably impossible.

Cheers,
Andrew

Chris_McKillop1 · February 28, 2001, 8:46pm

Andrew Thomas <Andrew@cogent.ca> wrote:

IP addresses are not unique on a machine. A single computer can
have multiple IP addresses. This is true for any IP network,
admittedly. It still poses a uniqueness problem.

I was going to comment on that. A single machine can have mutlitple
IP addresses, even multiple per interface and I am not sure exactly
how qnet works/handles all those situations.

I was not aware that QNET requires an IP address. What happens if
there is no IP network involved, or is IP an absolute prerequisite
for QNET? What about the case where both processes are on the same
node? How about ArcNet or Token Ring? If an IP address is
guaranteed to exist for all installations of QNET, how do I map an
IP address <—> nd? Or, I guess the real question is: How do I
open a connection given (IP address, pid, chid)?

I may have opened a can of worms I cannot control! The thing with
qnet now vs. fleet under QNX4 is that it is a lot more flexible. Right
now it uses IP so that it’s traffic is routable (feel free to step in
slap me around whenever xtang). But it is possible that it could
ride on something other than IP but then I am not sure what it would
do with the FQNN. Right now you can make the connection by taking
the IP, doing a reverse-lookup to get the name and then getting the
nd. I am not sure if the API will take a raw IP address and give
you the nd. However, you can do “cd /net/10.0.20.1/bin” and it will
work just as well as by name. This could be an internal handling
that isn’t exposed via any API.

If there is a good answer to 2), then this is a Good Idea. If IP
address is in fact sufficient to identify a node, then why do you have
node descriptors at all? Isn’t (IP addr,pid,chid) a better mechanism
than (nd,pid,chid) in all cases?

The reason it doesn’t take IP is that it is possible that it could
ride on something other then IP in the future and so to keep the same
semantics between them there is an abstraction of an nd. That way
the same API can be used to make a connection regardless of the lower
level protocol qnet uses.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Andrew_Thomas1 · March 1, 2001, 1:39am

“Chris McKillop” <cdm@qnx.com> wrote in message
news:97jo3g$741$1@nntp.qnx.com…

Andrew Thomas <> Andrew@cogent.ca> > wrote:
If there is a good answer to 2), then this is a Good Idea. If IP
address is in fact sufficient to identify a node, then why do you have
node descriptors at all? Isn’t (IP addr,pid,chid) a better mechanism
than (nd,pid,chid) in all cases?

The reason it doesn’t take IP is that it is possible that it could
ride on something other then IP in the future and so to keep the same
semantics between them there is an abstraction of an nd. That way
the same API can be used to make a connection regardless of the lower
level protocol qnet uses.

What you say makes complete sense, but it disqualifies IP address as
a part of a unique identifier. So…back to the drawing board. Are we
approaching the statement again that QNET contains no unique
identifiers? This makes the protocol pretty difficult to deal with in
the general case. Or, are you expecting that even if QNET rides on
another network it will still have an IP address somewhere in there,
much like PPP does now?

I was thinking a little more about the idea of the FQNN as being
the unique identifier, and have figured out why it doesn’t sit quite
right. TCP networks use names as a human-readable convenience
for the hard-to-remember unique identifier, the IP address. The
rules for DNS and /etc/hosts allow different machines to have
different names for the same IP address, even names that the
authoritative DNS (or /etc/hosts) doesn’t know about. Some
people may view this as a confusing or dangerous thing to do, but
it also has some very powerful uses, and it’s something that people
use regularly to perform redirection of services, for example. Since
QNET makes use of the configuration of TCP networks,
specifically the /etc/hosts and the DNS, it implies to anybody who
has not followed this thread that QNET follows the same set of rules
regarding naming. The earlier statement that Xiaodan made that
disagreements on names would be considered a mal-configured
network is in direct opposition to the current rules and usage of
the naming facilities that QNET is using. I think that if you want
to apply new semantics to name/IP mapping then it is not wise
to use the existing naming facilities. It is both confusing and
likely to be wrong.

Cheers,
Andrew

Chris_McKillop1 · March 1, 2001, 5:37pm

Andrew Thomas <andrew.nospam@cogent.ca> wrote:

What you say makes complete sense, but it disqualifies IP address as
a part of a unique identifier. So…back to the drawing board. Are we
approaching the statement again that QNET contains no unique
identifiers? This makes the protocol pretty difficult to deal with in
the general case. Or, are you expecting that even if QNET rides on
another network it will still have an IP address somewhere in there,
much like PPP does now?

I spent some time talking to xtang about this and I am now going to
do a QDN article on qnet and qnet issues. I think I have some
information that will help you now…

o qnet’s FQNN does not have to be the same as the FQN from DNS or tcp.
o qnet will get the FQNN from CS_HOSTNAME and CS_DOMAINNAME (kernel
resource strings) OR from the command line option “host=name.domain”.
o netmanager and hostname will populate the CS_HOSTNAME and
CS_DOMAINNAME values in the kernel so if you don’t give the
“host=…” option to qnet it will normally nab the tcpip name and domain
of the machine. You can also specify default values for these settings
on the command line to startup-* in the build file.
o On a local network (ie: broadcast-able subnet) qnet will use it’s own
“node discovery protocol” to figure out which node is which. You can
also have it use DNS by chaning the command line arguments for the
mountpoint. THe default “/net” mount is NDP, but you could add an
additional mount point “/internet” which would use DNS.
o The netmgr_strtond() call will resolve the name using NDP and/or DNS
based on how you setup the arguments to qnet.

So…now you can control your unique identifer using the “host=”
option to qnet regardless of the IP address of the interface it is using.
Since it will use NDP by default you are good for local network accesses
(which is probably fine if QNX4’s networking worked for you). And now I think
you can better see the reason for having netmgr_strtond() (I know that
it is clearer for me).

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Alain_Bonnefoy2 · March 2, 2001, 10:18am

<!doctype html public “-//w3c//dtd html 4.0 transitional//en”>

Chris McKillop a écrit :

Andrew Thomas <> wrote:
>
> What you say makes complete sense, but it disqualifies IP address as
> a part of a unique identifier. So...back to the drawing board. Are we
> approaching the statement again that QNET contains no unique
> identifiers? This makes the protocol pretty difficult to deal with in
> the general case. Or, are you expecting that even if QNET rides on
> another network it will still have an IP address somewhere in there,
> much like PPP does now?
>
I spent some time talking to xtang about this and I am now going to
do a QDN article on qnet and qnet issues. :wink: I think I have some
information that will help you now...

o qnet's FQNN does not have to be the same as the FQN from DNS or tcp.
o qnet will get the FQNN from CS_HOSTNAME and CS_DOMAINNAME (kernel
resource strings) OR from the command line option "host=name.domain".
o netmanager and hostname will populate the CS_HOSTNAME and
CS_DOMAINNAME values in the kernel so if you don't give the
"host=..." option to qnet it will normally nab the tcpip name and domain
of the machine. You can also specify default values for these settings
on the command line to startup-* in the build file.
o On a local network (ie: broadcast-able subnet) qnet will use it's own
"node discovery protocol" to figure out which node is which. You can
also have it use DNS by chaning the command line arguments for the
mountpoint. THe default "/net" mount is NDP, but you could add an
additional mount point "/internet" which would use DNS.
o The netmgr_strtond() call will resolve the name using NDP and/or DNS
based on how you setup the arguments to qnet.

So....now you can control your unique identifer using the "host="
option to qnet regardless of the IP address of the interface it is using.
Since it will use NDP by default you are good for local network accesses
(which is probably fine if QNX4's networking worked for you). And now I think
you can better see the reason for having netmgr_strtond() (I know that
it is clearer for me).

    chris

--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
                  "The faster I go, the behinder I get."
Chris McKillop                             -- Lewis Carroll --
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

So, it means that qnet only take care about the hostname.
If we use IP, an association will be done between this name and an IP address, because the IP stack knows using /etc/hosts to resolve it.
Now, If we use a different protocol (I mean; not ethernet), it's up to this protocol to supply a similar method to resolv the association between hostname and network address. Right?

Or, When you say :
"o On a local network (ie: broadcast-able subnet) qnet will use it's own
"node discovery protocol" to figure out which node is which."
Does it means that qnet only ask any kernel for their hostname and don't take care about any physical address?
Certainly not! how to contact a node after?

It's not so clear for me!

Alain.

Xiaodan_Tang1 · March 2, 2001, 8:02pm

I modified your post to get rid of the HTML Tags.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

So, it means that qnet only take care about the hostname.

QNET only care about the strings store in CS_HOSTNAME/CS_DOMAIN,
are these “tcpip hostname” ? Maybe yes (most time yes), Could
be no. Internally, QNET only associate a “name” to a “nd”.

When QNET try to talk to another “name” (node), the “name
resolver” kicks in try to determine “how to get to that name”.

The default “name resolver” is “node discover protocal” (NDP).
Which is pretty much like ARP, that is, it “broadcast”
the name wanted, with own name, and waiting for a reply.

How to “broadcast” you may ask. It depends on what QNET ride
on. We support IP/Ether now (build into QNET), so it will
“broadcast” with either “subnet.255” or “ffffffff” depends
on which protocol you set (bind=xx option).

QNET will only “specificly” translate a name into a IP
(by calling gethostbyname()), only if you told QNET that
“to resolve names under that directory, using DNS first,
(optional) then try NDP”. (mount=:resolver=,
or sth like that

Is this getting clear ?

-xtang

If we use IP, an association will be done between this name and an
IP address, because the IP stack knows using /etc/hosts to resolve it.
Now, If we use a different protocol (I mean; not ethernet), it’s up
to this protocol to supply a similar method to resolv the association between
hostname and network address. Right?
Or, When you say :
“On a local network (ie: broadcast-able subnet) qnet will use it’s own
node discovery protocol to figure out which node is which.”
Does it means that qnet only ask any kernel for their hostname and
don’t take care about any physical address?
Certainly not! how to contact a node after?
It’s not so clear for me!

IPC with nid,pid,chid - what nid?

chris \

chris

\