QNXRTP & QNX4 network

Hi,

We have a network of 9 QNX nodes (all licensed, 4.23A), and now have one QNX
Real Time Platform PC.

Question is can the QNX RTP platform communicate with the other 9 nodes
using the QNX network protocol ( non-TCP/IP )? I have not been able to get
the RTP computer to see the other 9 QNX nodes, except under TCP/IP.

Thanks,

Dale Pischke
dpischke@silentwitness.com

Dale Pischke <dale@gyyr.com> wrote:

Hi,

We have a network of 9 QNX nodes (all licensed, 4.23A), and now have one QNX
Real Time Platform PC.

Question is can the QNX RTP platform communicate with the other 9 nodes
using the QNX network protocol ( non-TCP/IP )? I have not been able to get
the RTP computer to see the other 9 QNX nodes, except under TCP/IP.

Nope, they can only communicate using TCP/IP.

-David

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

OK…I finally have to ask…

Did QNX do this just to piss off current customers? This makes smooth
migration of a QNX4 network to QNX6 nearly impossible. QSSL, what were you
thinking?

David Gibbs <dagibbs@qnx.com> wrote in message
news:a92be7$394$2@nntp.qnx.com

Dale Pischke <> dale@gyyr.com> > wrote:
Hi,

We have a network of 9 QNX nodes (all licensed, 4.23A), and now have one
QNX
Real Time Platform PC.

Question is can the QNX RTP platform communicate with the other 9 nodes
using the QNX network protocol ( non-TCP/IP )? I have not been able to
get
the RTP computer to see the other 9 QNX nodes, except under TCP/IP.

Nope, they can only communicate using TCP/IP.

-David

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

Hi Stephen

I’ve felt this way about many RTP issues, but let me come to their defense
on this one.

The networking methodologies are SO DIFFERENT that there was no way to make
them compatible and have even half the networking features that RTP has.

With RTP you can do native QNX networking across the globe as easily as
across the room. You can’t do that with QNX4. And native QNX networking is
SO MUCH nicer than TCP/IP networking.


“Stephen Thomas” <slthomas@corpDOTolin.com> wrote in message
news:a92dv0$b7c$1@inn.qnx.com

OK…I finally have to ask…

Did QNX do this just to piss off current customers? This makes smooth
migration of a QNX4 network to QNX6 nearly impossible. QSSL, what were
you
thinking?

David Gibbs <> dagibbs@qnx.com> > wrote in message
news:a92be7$394$> 2@nntp.qnx.com> …
Dale Pischke <> dale@gyyr.com> > wrote:
Hi,

We have a network of 9 QNX nodes (all licensed, 4.23A), and now have
one
QNX
Real Time Platform PC.

Question is can the QNX RTP platform communicate with the other 9
nodes
using the QNX network protocol ( non-TCP/IP )? I have not been able to
get
the RTP computer to see the other 9 QNX nodes, except under TCP/IP.

Nope, they can only communicate using TCP/IP.

-David

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

“Stephen Thomas” <slthomas@corpDOTolin.com> wrote in message
news:a92dv0$b7c$1@inn.qnx.com

OK…I finally have to ask…

Did QNX do this just to piss off current customers? This makes smooth
migration of a QNX4 network to QNX6 nearly impossible. QSSL, what were
you
thinking?

QNX protocol is infact a kernel to kernel type of protocol. Because the
QNX6
kernel has features/concept QNX4 doesn’t (and vice versa) getting QNX6 to
talk
to QNX4 is close to impossible.

  • Mario

Stephen Thomas <slthomas@corpdotolin.com> wrote:

OK…I finally have to ask…

Did QNX do this just to piss off current customers? This makes smooth
migration of a QNX4 network to QNX6 nearly impossible. QSSL, what were you
thinking?

QNX4 networking is an Ethernet protocol – all addressing done at the
MAC level. (Well, it could work on other hardware, but the addressing
is still at the hardware level.) This caused began to really limit what
could be done with QNX4 networking, in particular it was not a routable
protocol. Also, if you look at QNX4 messaging, a Reply() was to a
process, assuming a unique Send() point in a process – under QNX 6
there may not be a unique MsgSend() in a process (i.e. two threads in
the same process may both be SEND blocked on the same other process,
if a Reply() is directed to that process, which thread gets the Reply()?)

QNX6 networking is based on IP, so it is routable. But, this means that,
among other things, packet format, and other rules can not be compatible.

It was a case of having to break backwards compatibility to go forward,
where backwards compatibility would have prevented this.

QNX4 & QNX6 are different operating systems – in general, if you wish
to communicate between heterogenous OSes, TCP/IP is your best choice.

So, no, we weren’t trying to piss people off. We just couldn’t do what
we wanted & needed to do for QNX6 and still make it compatible with QNX4
networking.

For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

-David

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

David Gibbs wrote:


For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Hmmm, doesn’t the fact that this exists prove that it is not impossible
to do :wink: Seriously, why doesn’t QSSL buy this product, or produce
something similar ? It would be a useful addition to the portability kit.

ps: I thought qnet was designed to be transport re-hostable (i.e. it
doesn’t have to go over IP, it can be hosted directly on ethernet
frames, or 1394 frames, or pretty much anything).

Rennie

Thanks to all for replies to my message about QNX RTP & QNX 4.23A.

My goal of making the RTP computer a “QNX 4.XX Node” was only desired for
development, not for an end product.

It would have been nice, but I can certainly live with telneting in. As part
of our development, we program Flash Memory cards – which would have been
nice to do on the RTP computer, but might not be possible. No problem –
there’s always work-arounds.

Thanks again for all your replies…

Dale Pischke

I haven’t looked at this product. In short, does it emulate QNX6 IPC on
QNX4 or emulate QNX4 IPC on QNX6.

I think that the former would be easier but the latter is what most people
‘think’ they want. After all, it’s the old QNX4 people that want it.

“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB5BE3B.8000004@csical.com

David Gibbs wrote:


For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Hmmm, doesn’t the fact that this exists prove that it is not impossible
to do > :wink: > Seriously, why doesn’t QSSL buy this product, or produce
something similar ? It would be a useful addition to the portability kit.

ps: I thought qnet was designed to be transport re-hostable (i.e. it
doesn’t have to go over IP, it can be hosted directly on ethernet
frames, or 1394 frames, or pretty much anything).

Rennie

“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB5BE3B.8000004@csical.com

David Gibbs wrote:


For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Hmmm, doesn’t the fact that this exists prove that it is not impossible
to do > :wink: > Seriously, why doesn’t QSSL buy this product, or produce
something similar ? It would be a useful addition to the portability kit.

This is indeed an interesting product but is not transparent at all.
Client have to use custom api.

For example you wouldn’t be able to list a directory of a QNX6 machine
from QNX4. You wouldn’t be able to open a file etc. It “simply” provides
SRR and proxy/pulses services. It takes a LOT more to get
QNX4 and QNX6 tranparent interconnectivity.

ps: I thought qnet was designed to be transport re-hostable (i.e. it
doesn’t have to go over IP, it can be hosted directly on ethernet
frames, or 1394 frames, or pretty much anything).

Rennie

“Dale Pischke” <dale@gyyr.com> wrote in message
news:a94eqi$qc0$1@inn.qnx.com

Thanks to all for replies to my message about QNX RTP & QNX 4.23A.

My goal of making the RTP computer a “QNX 4.XX Node” was only desired for
development, not for an end product.

It would have been nice, but I can certainly live with telneting in.

You can phditto over IP,. By installing samba (server and client) on both
sides you can share files.

As part
of our development, we program Flash Memory cards – which would have been
nice to do on the RTP computer, but might not be possible. No problem –
there’s always work-arounds.

Thanks again for all your replies…

Dale Pischke

David Gibbs wrote:

Stephen Thomas <> slthomas@corpdotolin.com> > wrote:
OK…I finally have to ask…

Did QNX do this just to piss off current customers? This makes smooth
migration of a QNX4 network to QNX6 nearly impossible. QSSL, what were you
thinking?

QNX4 networking is an Ethernet protocol – all addressing done at the
MAC level. (Well, it could work on other hardware, but the addressing
is still at the hardware level.) This caused began to really limit what
could be done with QNX4 networking, in particular it was not a routable
protocol. Also, if you look at QNX4 messaging, a Reply() was to a
process, assuming a unique Send() point in a process – under QNX 6
there may not be a unique MsgSend() in a process (i.e. two threads in
the same process may both be SEND blocked on the same other process,
if a Reply() is directed to that process, which thread gets the Reply()?)

QNX6 networking is based on IP, so it is routable. But, this means that,
among other things, packet format, and other rules can not be compatible.

It was a case of having to break backwards compatibility to go forward,
where backwards compatibility would have prevented this.

QNX4 & QNX6 are different operating systems – in general, if you wish
to communicate between heterogenous OSes, TCP/IP is your best choice.

So, no, we weren’t trying to piss people off. We just couldn’t do what
we wanted & needed to do for QNX6 and still make it compatible with QNX4
networking.

For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

you also might try looking at:

http://www.sf.net/projects/openqnx → PVM.

PVM provides message passing services based on UDP.
It works since years with clusters with up to 192 systems and is
available for QNX4 and QNX6 at souceforge.


Armin





-David

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

Mario Charest wrote:

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB5BE3B.8000004@csical.com> …
David Gibbs wrote:


For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Hmmm, doesn’t the fact that this exists prove that it is not impossible
to do > :wink: > Seriously, why doesn’t QSSL buy this product, or produce
something similar ? It would be a useful addition to the portability kit.

This is indeed an interesting product but is not transparent at all.
Client have to use custom api.

For example you wouldn’t be able to list a directory of a QNX6 machine
from QNX4. You wouldn’t be able to open a file etc. It “simply” provides
SRR and proxy/pulses services. It takes a LOT more to get
QNX4 and QNX6 tranparent interconnectivity.

NFS, SAMBA … and message passing by PVM does the job :slight_smile:

Armin

ps: I thought qnet was designed to be transport re-hostable (i.e. it
doesn’t have to go over IP, it can be hosted directly on ethernet
frames, or 1394 frames, or pretty much anything).

Rennie

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CB68DCA.B1E84FBB@web_.de…

Mario Charest wrote:

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB5BE3B.8000004@csical.com> …
David Gibbs wrote:


For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might
try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Hmmm, doesn’t the fact that this exists prove that it is not
impossible
to do > :wink: > Seriously, why doesn’t QSSL buy this product, or produce
something similar ? It would be a useful addition to the portability
kit.

This is indeed an interesting product but is not transparent at all.
Client have to use custom api.

For example you wouldn’t be able to list a directory of a QNX6 machine
from QNX4. You wouldn’t be able to open a file etc. It “simply”
provides
SRR and proxy/pulses services. It takes a LOT more to get
QNX4 and QNX6 tranparent interconnectivity.

NFS, SAMBA … and message passing by PVM does the job > :slight_smile:

That’s not transparent as per QNX4 and QNX6 definition of native
networking…

Armin



ps: I thought qnet was designed to be transport re-hostable (i.e. it
doesn’t have to go over IP, it can be hosted directly on ethernet
frames, or 1394 frames, or pretty much anything).

Rennie

David Gibbs <dagibbs@qnx.com> wrote:

For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Interesting, but crazy prices!
Half of ONX4 price per node …

Andy

-David

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

<andy@microstep-mis.com> wrote in message
news:a96jgg$kph$1@charon.microstep-mis.sk

David Gibbs <> dagibbs@qnx.com> > wrote:

For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Interesting, but crazy prices!
Half of ONX4 price per node …

Ouch, that’s bad given that QNX6 is cheaper then QNX4

Andy

-David

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

andy@microstep-mis.com wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:

For QNX4 style messaging between QNX4 & QNX6 (& Linux), you might try
looking at:

http://www.bitctrl.com/produkte/qoip/kurzdok.htm

Interesting, but crazy prices!
Half of ONX4 price per node …

I never looked at the prices – just pointing out the technology.

-David

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

Mario Charest wrote:

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB5BE3B.8000004@csical.com> …

This is indeed an interesting product but is not transparent at all.
Client have to use custom api.

For example you wouldn’t be able to list a directory of a QNX6 machine
from QNX4. You wouldn’t be able to open a file etc. It “simply” provides
SRR and proxy/pulses services. It takes a LOT more to get
QNX4 and QNX6 tranparent interconnectivity.

I don’t think that most people migrating from QNX4 → QNX6 need
transparent interconnectivity. They simply need a model that
structurally resembles QNX4 SRR, so that they can incrementally migrate
processes from QNX4 to QNX6. It is more of a porting tool, than
something that would be deployed.

Rennie

Rennie Allen <rallen@csical.com> wrote in message
news:3CBAF3F5.2020208@csical.com

Mario Charest wrote:

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3CB5BE3B.8000004@csical.com> …

This is indeed an interesting product but is not transparent at all.
Client have to use custom api.

For example you wouldn’t be able to list a directory of a QNX6 machine
from QNX4. You wouldn’t be able to open a file etc. It “simply”
provides
SRR and proxy/pulses services. It takes a LOT more to get
QNX4 and QNX6 tranparent interconnectivity.


I don’t think that most people migrating from QNX4 → QNX6 need
transparent interconnectivity. They simply need a model that
structurally resembles QNX4 SRR, so that they can incrementally migrate
processes from QNX4 to QNX6. It is more of a porting tool, than
something that would be deployed.

This is only true for people that are using QNX to build embedded devices.
For customers using dozens of QNX4 nodes in a distributed environment (e.g.
a distributed control system), it is unfeasible to do a single massive
upgrade to QNX6. Thus the concept of a “migration”

Regards,
Stephen

Rennie