How to boot with -ptcpip [was: netstat and route]

bridged with qdn.public.qnxrtp.os
Post Reply
Mario Charest

Re: Thead Priority

Post by Mario Charest » Mon May 27, 2002 11:02 am

"Chris McKillop" <cdm@qnx.com> wrote in message
news:acst3j$nq6$1@nntp.qnx.com...
[Moving this to .os]
The real beauty of QNX4's network transparency
was that you did things IDENTICALLY whether then network
was involved or not.
Not entirely true, for some operation you had to use qnx_proxy_rem_attach()
over qnx_proxy_attach()

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over
a
networked system? So we are urged to use a resource manager, but how?
Should
we write a QNX6 version of nameloc?
I think Cogent has a name server for QNX4 and QNX6 and LINUX.

The QNX4 version of nameloc isn't that great you know. There are lots
of situation where it creates problem. Over the year I beleive people
learn to deal with them hence over time forget that it's not that great.
Another thing I found light-years ahead of QNX4 was the push to use
resmgrs
so that all applications can use the POSIX APIs to communicate to the
managers over the network.
I agree Chris, but what was never made clear anywhere is the cost in
overhead.
Resmgr are expensive and slow down messaging by a factor of ~3 over non
resmgr. True resmgr do more so that's to be expected and I am using them
all over the place ;-) But when I was told to use read/write instead of
MsgSend
I was never told it would be 3 times slower.
So I am not so sure if the baby was tossed with the bathwater or if the
baby
just grew up and a new baby came along.
Or if the parent though their baby was the greatest ever and wouldn't
even consider some other parents baby would be better than theirs!
chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Xiaodan Tang

Re: Thead Priority

Post by Xiaodan Tang » Mon May 27, 2002 3:20 pm

Thought I should join the party.
"Chris McKillop" <cdm@qnx.com> wrote in message
news:acst3j$nq6$1@nntp.qnx.com...
[Moving this to .os]
The real beauty of QNX4's network transparency
was that you did things IDENTICALLY whether then network
was involved or not.
The idea of "walking under /net", could easily put in "name_open()",
so that the application API (name_open()) is consistent in local/global
case.

For "QNET over serial", our thoughts is we've put QNET over IP, so
as long as the IP network could reach, it doesn't metter it is through
a "serial line", "ppp over ethernet", or "ip over atm"... QNET just
use the TCP/IP network.

It might be the case that we didn't document enough samples how to
use QNET over IP.

The "ndp" is a protocol based on broadcasting, since PPP is not
"broadcastable", that's why you don't get informations from the
otherside.

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)

A "nameloc" on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).
OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?
We difinitly don't want to abandon the "name location" concept.

I will let others comment how to improve resmgr performance.

-xtang

Mario Charest

Re: Thead Priority

Post by Mario Charest » Mon May 27, 2002 4:15 pm

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)
Are you sure about this??? I'm very confident it's NOT using broadcast.
A "nameloc" on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).

OK, so if we are to abandon the QNX4 concept of name location, then
what
is/are the recommended method(s) whereby processes can make contact
over a
networked system? So we are urged to use a resource manager, but how?
Should
we write a QNX6 version of nameloc?

We difinitly don't want to abandon the "name location" concept.

I will let others comment how to improve resmgr performance.

-xtang

Andrew Thomas

Re: Thead Priority

Post by Andrew Thomas » Mon May 27, 2002 4:37 pm

Mario Charest wrote:
I think Cogent has a name server for QNX4 and QNX6 and LINUX.
Since you bring it up ... ;-)

Yes, we do have a name server that works across the
network. You have to use our API in order to use it,
but the underlying facility is still the QNX networking,
not a crazy kluge on TCP. The upside of using our
API is that your code will port to QNX4 and Linux without
modifications (at least none related to message passing).

Cheers,
Andrew

Xiaodan Tang

Re: Thead Priority

Post by Xiaodan Tang » Mon May 27, 2002 4:53 pm

Mario Charest <goto@nothingness.com> wrote:
Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)

Are you sure about this??? I'm very confident it's NOT using broadcast.
You are right. (Guess I should check more careful of the source)

It is "reliable" in the sense that "attach()" and "query()" are
all goes to the master. It is not "reliable" to sync the masters
so if you have multiple nameloc running, things COULD goes wrong.
(or I am still not correct on this part?)

Anyway, we realized the "server/client" model could greatly improve
the reliability, but it sort of against the "pure distributed" idea,
and of cause, sync/re-elect master could be another headache.

-xtang

Mario Charest

Re: Thead Priority

Post by Mario Charest » Mon May 27, 2002 6:56 pm

"Xiaodan Tang" <xtang@qnx.com> wrote in message
news:actoap$cm2$1@nntp.qnx.com...
Mario Charest <goto@nothingness.com> wrote:

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.

(it also based on a broadcast to populate the name space)

Are you sure about this??? I'm very confident it's NOT using broadcast.

You are right. (Guess I should check more careful of the source)
You had me worry I had to go tell everyone I told QNX4
is not using broadcast I was wrong ;-)
It is "reliable" in the sense that "attach()" and "query()" are
all goes to the master. It is not "reliable" to sync the masters
so if you have multiple nameloc running, things COULD goes wrong.
(or I am still not correct on this part?)
Master (nameloc) are not synchronising with each other.
A node may use different master from time to time giving
different behavior depending on which master it's using.
Anyway, we realized the "server/client" model could greatly improve
the reliability, but it sort of against the "pure distributed" idea,
and of cause, sync/re-elect master could be another headache.

-xtang

David Gibbs

Re: Thead Priority

Post by David Gibbs » Mon May 27, 2002 7:41 pm

Mario Charest <goto@nothingness.com> wrote:
"Chris McKillop" <cdm@qnx.com> wrote in message
news:acst3j$nq6$1@nntp.qnx.com...
[Moving this to .os]
The real beauty of QNX4's network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

Not entirely true, for some operation you had to use qnx_proxy_rem_attach()
over qnx_proxy_attach()
QNX4 stuff:

Actually, in both local and remote, you had to use qnx_proxy_attach().
In the remote case, you had the additional step of needing to use
qnx_proxy_rem_attach(). BUT, if you coded for the remote case,
using qnx_proxy_rem_attach(), it would work transparently in the
local case as well. So, it was not (quite) identical in the
remote case to the local case, but the local case could be
identical to the remote case. (A fine distinction.)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Guest

Re: Thead Priority

Post by Guest » Tue May 28, 2002 5:39 pm

Just as an aside, there might (will) hopefully be an article
coming out on this topic, but in the mean time you can fiddle
with the following:

http://www.gweebo.com/~thomasf/
http://www.gweebo.com/~thomasf/Docs/name-example.tar.gz

Thomas

Xiaodan Tang <xtang@qnx.com> wrote:
Thought I should join the party.

"Chris McKillop" <cdm@qnx.com> wrote in message
news:acst3j$nq6$1@nntp.qnx.com...
[Moving this to .os]
The real beauty of QNX4's network transparency
was that you did things IDENTICALLY whether then network
was involved or not.

The idea of "walking under /net", could easily put in "name_open()",
so that the application API (name_open()) is consistent in local/global
case.

For "QNET over serial", our thoughts is we've put QNET over IP, so
as long as the IP network could reach, it doesn't metter it is through
a "serial line", "ppp over ethernet", or "ip over atm"... QNET just
use the TCP/IP network.

It might be the case that we didn't document enough samples how to
use QNET over IP.

The "ndp" is a protocol based on broadcasting, since PPP is not
"broadcastable", that's why you don't get informations from the
otherside.

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)

A "nameloc" on Qnx6 is very easy to write, the story is how
reliable it could be, and weather we should move that part
into QNET (or leave it a stand along process).

OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?

We difinitly don't want to abandon the "name location" concept.

I will let others comment how to improve resmgr performance.

-xtang
--
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/

Shashank

Re: Moving to QNX RTP

Post by Shashank » Wed May 29, 2002 2:19 pm

Hi,
We have developed a real-time application in QNX 4.25.
But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
some information on how to
port code from 4.25 to RTP if in the future we decide to
move to QNX RTP.

Thank you,
Shashank

Robert Krten

Re: Moving to QNX RTP

Post by Robert Krten » Wed May 29, 2002 2:22 pm

Shashank <sbalijepalli@precitech.com> wrote:
Hi,
We have developed a real-time application in QNX 4.25.
But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
some information on how to
port code from 4.25 to RTP if in the future we decide to
move to QNX RTP.
Wow, today is "shameless plug day" :-)

Visit www.parse.com, and look at the "Getting Started with QNX Neutrino book"
on that site. There's a table of contents, as well as a sample chapter.
One of the latter chapters in the book talks about QNX 4 -> Neutrino
migration...

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Steve Reid

Re: Moving to QNX RTP

Post by Steve Reid » Wed May 29, 2002 2:48 pm

Shashank <sbalijepalli@precitech.com> wrote:
: Hi,
: We have developed a real-time application in QNX 4.25.
: But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
: some information on how to
: port code from 4.25 to RTP if in the future we decide to
: move to QNX RTP.

Take a look at the QNX 4 to QNX 6 Migration Guide. It's on the QDN website
and will be shipped with QNX 6.2.

------------------------------------------
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
------------------------------------------

David Gibbs

Re: Moving to QNX RTP

Post by David Gibbs » Wed May 29, 2002 3:42 pm

Shashank <sbalijepalli@precitech.com> wrote:
Hi,
We have developed a real-time application in QNX 4.25.
But, I guess QNX will stop supporting QNX 4.25 from 2005. Where can we find
some information on how to
port code from 4.25 to RTP if in the future we decide to
move to QNX RTP.
There should be a migration toolkit available for free. It comes
with a migration document that talks about changes, and how to go
about performing the migration, and a migration library that can
help with the first stages of a port, and a utility that will walk
your code looking for things that might need to be changed and
suggesting replacement routines.

For more information:

http://qdn.qnx.com/download/migration/index.html


We also offer a migration course, for more information, contact:
training@qnx.com or your sales rep.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Guest

Re: Thead Priority

Post by Guest » Wed May 29, 2002 9:38 pm

Xiaodan Tang <xtang@qnx.com> wrote:
The idea of "walking under /net", could easily put in "name_open()",
so that the application API (name_open()) is consistent in local/global
case.
Exactly. This is what I would like to see. The name_locate / name_attach
were most useful in the sense that they abstracted the service from the actual
network node that provided it. While walking /net isn't that difficult, having
to add that to each client app is tedious, this is something that belongs wrapped
by an API function. I'm not even going to mention the potential added complexity
when qnet told to use something other then /net :-)
Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)
I'm not even suggesting that we need anything like a nameloc, as the only
advantage it would have is as a cache of the various /net entries.

As for the issue of systems connected via PPP or IPSec tunnels not showing
up, isn't there some command line that can be issued to make them appear?
If so, then that could just be added to ip_up script (and ip_down).

I think all we need is something like this:

fd = name_locate( "global_name" );

Which of course means that we need to document a standard location for the
global namespace to exist. ie. /var/net or something like that.

The thing is for this to be useful it has to more or less be promoted as a
"standard" from QSSL. Otherwise there is no reason for anyone to follow the
same namespace/directory locations for global names.

Cheers,
Camz.

Guest

Re: Thead Priority

Post by Guest » Wed May 29, 2002 10:03 pm

Chris McKillop <cdm@qnx.com> wrote:
I think the idea is to find the processes by always using /net. In the
local case you can use "/net/localhost/" and if you need to talk to a remote
machine you can use "/net/machinename". This doesn't cover global names
but the reality is you generally know the name of the machine you want to
talk to anyways.
This is potentially error prone. /net does not exist if qnet isn't running, but
if you use something that isn't dependant on /net... ie. /var/net then the
name_locate function could simply look there first and then walk /net if it
exists. As for knowing the name of the machine, that's completely opposite
of why you want a global namespace. I *don't* want to know the name of the
machine, because it can change. During development/testing, I might have
all the processes/resmgrs running on the same machine, but when I deploy, it
might be different, and possibly distributed. So, I think this is a bad idea
unless you make your app use some kind of configuration file that you can
edit, but even that is something that you don't really need if you make the
namespace transparent.
One of the issues that I personally didn't like about how naming worked on
QNX4 was the fact that you where basically forced to use the global name
space to communicate between two nodes and when there where mulitple
registrations of the same global name sometimes things worked out kinda funny.
Agreed. I actually liked the QNX2 method where the uniqueness of global names
was enforced (ie. you could not attach a duplicate name). True, the QNX4 ability
to have multiple allowed for the situation of some failover transparency, but
it could be rather complex to get it right. For the most part, I think developers
tried to avoid having duplicate names unless absolutely neccesary.
the case of multiple machines with the same named resource. Perhaps using
an open standard like LDAP or some other open scheme.
I hadn't thought of LDAP. That's an interesting idea, but is also pretty
heavy in terms of solutions, especially when working with small embedded systems.
For the larger systems that might have LDAP for other reasons, it's a perfect
fit.
Another thing I found light-years ahead of QNX4 was the push to use resmgrs
so that all applications can use the POSIX APIs to communicate to the
managers over the network.
The push would have been ignored if they API hand not made it so easy. The
same push existed in QNX4, but it still wasn't _that_ easy, so it was rarely
done outside of QSSL. QNX4 still had some black magic associated with the
technique as well. QNX6 has some black magic required when you want to handle
directories rather than individual entries, and that needs to be addressed in
the docs (as I am sure it will).
Using a global name is pretty much useless if you want to use perl to talk
to your service.
Well, this depends. :-) If you use name_attach() and name_locate(), then you
could have a resmgr manage the /var/net space and perform a redirect/symlink
type service to point to the actual resource in /net/machine/... then you COULD.
Mind you, there isn't any reason why you can't have a resmgr sit "on top" of /var/net
and examine those requests to determine if it needed to let them pass-thru or
be redirected, somewhat like fs-pkg does already.

There is a related topic (cdm: you knew this was coming), which is remote spawn,
which is, IMO the other requirement of being able to actually create distributed
systems.

Right now remote spawn *IS* possible, but it needs to be wrapped up in an API call
of some sort to move it out of the realm of "guru black magic".

Cheers,
Camz.

Xiaodan Tang

Re: Thead Priority

Post by Xiaodan Tang » Thu May 30, 2002 12:53 am

camz@passageway.com wrote:
Xiaodan Tang <xtang@qnx.com> wrote:

Now back to the global name staff, I agree the name under /net
is not 100% reliable, it based on broadcasting after all.
But my feeling is "nameloc" on QNX 4 is also not 100% reliable.
(it also based on a broadcast to populate the name space)

I think all we need is something like this:

fd = name_locate( "global_name" );
This is exactly name_open() does.

fd = name_open("service_name", FLAG_GLOBAL);

pass in FLAG_LOCAL to enforce it only search local service.
Which of course means that we need to document a standard location for the
global namespace to exist. ie. /var/net or something like that.
Well, we didn't doc it, but actually it is in /dev/name/global/<services>,
we only need a manager (nameloc !:) to manage this name space, and
name_attach("service_name", FLAG_GLOBAL) well always talk to master
nameloc to regist the service (I am nodeX, provide service "service_name").
All the name_open(FLAG_GLOBAL) then looking at local /dev/name/global
first, if services not exist, contact master nameloc, and create
a symlink in to local global name space.

Now, allow duplicate service name or not, is just a switch on master
nameloc.

Use a "master manager", is the only way to make the whole thing
reliable. Otherwise, you have to relay name infos between managers,
and sync is always the problem.

-xtang

Post Reply

Return to “qdn.public.qnxrtp.os”