I’ve got a client/server setup and wish to use ConnectAttach() for
message passing. I can’t get the remote PID (on the server) from the
client, although according to Krten in Neutrino 2 all I have to do is
“perform a simple open() of the pathname.” Further references in the
book don’t clarify it (for me anyway). Can anyone help?
PS I’m using 6.1
TIA
Ron
You have to use a resmgr and qnet. Once you have a path space registered
by your server (the resmgr) you can use open() on that pathspace using
the form /dev/machine/path/you/registered. Rob’s book covers writing a
resmgr as do our docs.
chris
Ron <father_ron@catholic.org> wrote:
I’ve got a client/server setup and wish to use ConnectAttach() for
message passing. I can’t get the remote PID (on the server) from the
client, although according to Krten in Neutrino 2 all I have to do is
“perform a simple open() of the pathname.” Further references in the
book don’t clarify it (for me anyway). Can anyone help?PS I’m using 6.1
TIA
Ron
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
It is not clear whether your ‘remote’ server is on remote node or just
another process on the same node. In either case, to be able to use open()
the server has to be a ‘resource manager’, which means it must handle
certain set of predefined system messages. There’s documentation for writing
one, but it is far from trivial, especially for a newbie.
My personal recommendation is, avoid using QNX low-level messaging unless
you have to. The only case when you need it is
when you need clients to be able to use open/read/write API (i.e., you’re
writing a server which should be able to serve existing standard clients
that you did not write, such as general purpose utilities like ‘cat’, ‘cp’,
‘ls’, etc). Then see above - you have to make your server a resource
manager.
For two-way communication between a server and client(s) that you write
(i.e., they do not need to follow any standard API) you’ll be better off
with TCP/IP messaging or POSIX message queues. From 6.2 and later you can
also use UNIX domain sockets.
The benefits are numerous. Your code can be made portable and since you use
well-known API other people will have much better time inheriting/supporting
your code eventually. There’s plenty of books and code samples, tools to
debug the communication protocol (tcpdump and ethernet/IP analyzers). It is
easier to find developers. Finally, the communication is asynchronous. That
means your software will be less prone to ‘hangup’ issues plaguing
synchronous-messaging based designs. It is easier to maintain and evolve.
– igor
“Ron” <father_ron@catholic.org> wrote in message
news:b9c3kc$509$1@inn.qnx.com…
I’ve got a client/server setup and wish to use ConnectAttach() for
message passing. I can’t get the remote PID (on the server) from the
client, although according to Krten in Neutrino 2 all I have to do is
“perform a simple open() of the pathname.” Further references in the
book don’t clarify it (for me anyway). Can anyone help?PS I’m using 6.1
TIA
Ron
Ron,
You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d 
Asyncronous messaging isn’t as good as it sounds. If you want multiple
clients wanting the same data, you have to manage that yourself. Also, the
client doesn’t have control over the rate at which the messages are comming,
and it doesn’t work in the local case, only network, so it’s harder to
debug. Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a programmer has
struggled with the continious nature of data arriving with regards to state
behavior. It would take me too long to go into specifics, but this is more
of a personal issue, I just don’t like it (so yeah…I’ll find its
problems!).
As with UNIX domain sockets, they don’t work in the network case (i.e. you
can’t find them across the network). You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.
On the other hand, QNX low level messge passing , the resource manager
framework and QNET allow you can write an app and have it communicate over
the network or in the local case w/o programming changes. It makes for a
great foundation for a high degree of distribution of your application. The
only thing you need to know is the name of the app/sever. You don’t need to
manage port numbers and you can test it locally and then have it work the
same over the network (this means you don’t need networking debugging tools
in the first place).
QNET/QNX low level message passing is different in many ways to TCP/IP, but
I think it is easier, and you won’t have hangup problems if you treat
servers like servers (i.e. they don’t send messages to clients (except for
pulses, they are asyncronous)) and client like clients (MsgSend()s originate
with the client).
QNX low level message passing uses much less CPU time and less network
bandwith (if that kind of thing is still important to you).
Yeah…it’s not portable, but so what? In the real-time control case…I
don’t really care because I’m not going to port this to Linux/UNIX. The
only thing you can make portable anyway are the clients of a resource
manager (i.e. they stick to open/read/writes/devctrls . The resource
manager isn’t going to be portable because the resource manager framework
itself is a QNX thing.
The only exception I would make is that if you make your resource manager
adhere to opens, reads and writes, you can use one of the TCP/IP file
sharing things (Samba, NFS) to get/set data to your resource manager, which
is cool.
Also, another plus for resource managers, is I think they are a lot easier
than writing UNIX/Linux kernel code to make stuff available in the pathname
space.
BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve for new
programmers on a project, but give me a break…how hard is QNX message
passing compared to TCP/IP? And just how much time would a new developer
have to spend learning this stuff in order to be productive? I mean,
really…the hardest thing about the resource manager framework for me were
the docs, as soon as I had a couple of examples, I was ok. So now, not only
does the new developer have the docs, he’s got an entire system based on the
resource manager framekwork, Quelle example!
END RANT:
Kevin
“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:b9c79e$8jc$1@inn.qnx.com…
It is not clear whether your ‘remote’ server is on remote node or just
another process on the same node. In either case, to be able to use open()
the server has to be a ‘resource manager’, which means it must handle
certain set of predefined system messages. There’s documentation for
writing
one, but it is far from trivial, especially for a newbie.My personal recommendation is, avoid using QNX low-level messaging unless
you have to. The only case when you need it is
when you need clients to be able to use open/read/write API (i.e., you’re
writing a server which should be able to serve existing standard clients
that you did not write, such as general purpose utilities like ‘cat’,
‘cp’,
‘ls’, etc). Then see above - you have to make your server a resource
manager.For two-way communication between a server and client(s) that you write
(i.e., they do not need to follow any standard API) you’ll be better off
with TCP/IP messaging or POSIX message queues. From 6.2 and later you can
also use UNIX domain sockets.The benefits are numerous. Your code can be made portable and since you
use
well-known API other people will have much better time
inheriting/supporting
your code eventually. There’s plenty of books and code samples, tools to
debug the communication protocol (tcpdump and ethernet/IP analyzers). It
is
easier to find developers. Finally, the communication is asynchronous.
That
means your software will be less prone to ‘hangup’ issues plaguing
synchronous-messaging based designs. It is easier to maintain and evolve.– igor
“Ron” <> father_ron@catholic.org> > wrote in message
news:b9c3kc$509$> 1@inn.qnx.com> …
I’ve got a client/server setup and wish to use ConnectAttach() for
message passing. I can’t get the remote PID (on the server) from the
client, although according to Krten in Neutrino 2 all I have to do is
“perform a simple open() of the pathname.” Further references in the
book don’t clarify it (for me anyway). Can anyone help?PS I’m using 6.1
TIA
Ron
“Kevin Stallard” <kevin@fffflyingrobbbotsss.com> wrote in message
news:b9cim1$jit$1@inn.qnx.com…
Ron,
You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d >
Actually, he was not. You however are about to be. As they sing, ‘you had it
coming’… Pop, click, squish, Cicero…
Asyncronous messaging isn’t as good as it sounds. If you want multiple
clients wanting the same data, you have to manage that yourself.
Ever heard of multicast?
Also, the
client doesn’t have control over the rate at which the messages are
comming,
In synchronous case, clients implicitly do flow control by means of reply.
In asynchronous case either buffering or protocol-level flow control (e.g.,
TCP) takes care of that.
and it doesn’t work in the local case, only network, so it’s harder to
debug.
What exactly does not work in local case?
Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a programmer has
struggled with the continious nature of data arriving with regards to
state
behavior.
As russian saying goes, ‘there flew two flies - one was green, the other
flew to the right’. Meaning you’re confusing/mixing two things. Lack of
message boundaries has nothing to do with communication being asynchronous.
UDP has message boundaries, being asynchronous. There are funky protocols
like LAPD-over-UDP for people who don’t want boundary-lessness of TCP but
need reliability (so they can’t use plain UDP).
It would take me too long to go into specifics, but this is more
of a personal issue, I just don’t like it (so yeah…I’ll find its
problems!).
Woa, finally here comes a statement that can be called accurate
As with UNIX domain sockets, they don’t work in the network case (i.e. you
can’t find them across the network).
You can use AF_INET domain for network/local communication and AF_UNIX for
local, whichever suits you. UNIX domain has some distinct advantage for
local communications. Better security for example. In both cases you use
very much the same API (sockets).
You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.
Connecting to a remote server over IP has nothing to do with DNS. DNS is a
name resolution service, which is merely a convinience and is not required
for communications at all. And if you’re uncomfortable with port numbers,
what stops you from defining a service name and then translating it into a
port using getservicebyname()?
I am reluctant to ask also if you perhaps heard of RPC which makes the whole
thing more or less transparent (you can make remote function calls).
On the other hand, QNX low level messge passing , the resource manager
framework and QNET allow you can write an app and have it communicate over
the network or in the local case w/o programming changes.
Ughm… Cough… cough… cough. Right. Only there’s no global name service.
And you can’t send remote pulses (not until 6.2.1). Don’t get me wrong, I
don’t want to just diss QNX messaging. It has its use. However picturing it
as superior to IP is wishful zealous thinking. On the contrary, synchronous
IPC design does not lend well to networked designs at all, simply because
network medium in most cases is neither deterministic, nor reliable
(granted, when there is a suitable medium, QNX IPC would be better for
realtime communications, but I somehow doubt that is the case implied here).
There’s nothing more annoying in real life than clients, which hang
indefinitely on requests that are not going to be answered. Gets twice as
annoying when you also can’t even kill them (which happens a lot in QNX
case).
It makes for a
great foundation for a high degree of distribution of your application.
The
only thing you need to know is the name of the app/sever. You don’t need
to
manage port numbers and you can test it locally and then have it work the
same over the network (this means you don’t need networking debugging
tools
in the first place).
That whole paragraph can be said about IP messaging as well.
QNET/QNX low level message passing is different in many ways to TCP/IP,
but
I think it is easier, and you won’t have hangup problems if you treat
servers like servers (i.e. they don’t send messages to clients (except
for
pulses, they are asyncronous)) and client like clients (MsgSend()s
originate
with the client).
Right. You’re not gonna have any hangups if you don’t make any mistakes so
your code doesn’t have any bugs. I am sure yours doesn’t. Surprizes the hell
out of me that QNX’s shipped code does. One would assume THEY know how to
write QNX clients & servers, no?
QNX low level message passing uses much less CPU time and less network
bandwith (if that kind of thing is still important to you).
Wanna have a wager on speed of a file copy using QNET and TCP? How much you
wanna bet?
Yeah…it’s not portable, but so what? In the real-time control case…I
don’t really care because I’m not going to port this to Linux/UNIX. The
only thing you can make portable anyway are the clients of a resource
manager (i.e. they stick to open/read/writes/devctrls . The resource
manager isn’t going to be portable because the resource manager framework
itself is a QNX thing.
Sure thing. Unless one day QNX is sold to someone and/or goes the way of
Do-Do. I hope it doesn’t, but I don’t have a crystal ball. The next day
you’re stuck with legacy code that uses proprietary end-of-life API. Now if
that was only resmgrs/drivers, it is manageable. In real life most of the
systems’ complexity tends to be in the client side (protocol servers,
management, GUI) which would be reasonably easily portable to any POSIX
platform. But if the whole enchilada is written in proprietary API, it is
gonna be endless legacy nightmare. Probably end of your project too. If your
business people are any good, they usually like to have some kind of
insurance for business risks. Always have a ‘plan B’, so to speak.
The only exception I would make is that if you make your resource manager
adhere to opens, reads and writes, you can use one of the TCP/IP file
sharing things (Samba, NFS) to get/set data to your resource manager,
which
is cool.Also, another plus for resource managers, is I think they are a lot easier
than writing UNIX/Linux kernel code to make stuff available in the
pathname
space.
Another accurate statement, after all. Yes, writing (or to be precise,
debugging) QNX resmgrs is easier than equivalent Unix/Linux kernel code. I
never said otherwise, nor I am intended to. What I said is use QNX
proprietary API only to write QNX-specific pieces of code, such as resmgrs &
drivers. Anything else is better served by portable APIs.
BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve for new
programmers on a project, but give me a break…how hard is QNX message
passing compared to TCP/IP? And just how much time would a new developer
have to spend learning this stuff in order to be productive? I mean,
really…the hardest thing about the resource manager framework for me
were
the docs, as soon as I had a couple of examples, I was ok. So now, not
only
does the new developer have the docs, he’s got an entire system based on
the
resource manager framekwork, Quelle example!
END RANT:
Have you tried to teach a team of 20-30 people of different backgroubds and
skills level how to use QNX messaging properly? Let alone how to write
resmgrs… You should try.
Now, “you’ve been Igor’d”.
– igor (who has 10 years of total QNX experience including 5 with QNX6 and
actually likes it)
Hi Igor,
“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:b9cu0l$1ep$1@inn.qnx.com…
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9cim1$jit$> 1@inn.qnx.com> …
Ron,You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d >
Actually, he was not. You however are about to be. As they sing, ‘you had
it
coming’… Pop, click, squish, Cicero…
Wwwhhhhooooeeee…hang on boys, we’re in for a ride! 
Asyncronous messaging isn’t as good as it sounds. If you want multiple
clients wanting the same data, you have to manage that yourself.Ever heard of multicast?
Yeah, but does the QNX stack support it? And I’m speaking from an embedded
perspective…it would require a fair amount of additional overhead.
Also, the
client doesn’t have control over the rate at which the messages are
comming,In synchronous case, clients implicitly do flow control by means of reply.
In asynchronous case either buffering or protocol-level flow control
(e.g.,
TCP) takes care of that.
I didn’t mean flow control. I was referring to applications that need to
know just how fast data is arriving, or that don’t need data at the same
rate as other applicatons. Digital filters need to know how fast data is
arriving. It is useful to have this. It is a pain to implement it on the
server side of a server that takes the initiative of sending the data…
and it doesn’t work in the local case, only network, so it’s harder to
debug.What exactly does not work in local case?
Forget I said it, I had address families mixed up with socket types.
Ok…you can have a AF_UNIX combined with SOCK_DGRAM to get local UDP…it
was late last night…
Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a programmer
has
struggled with the continious nature of data arriving with regards to
state
behavior.As russian saying goes, ‘there flew two flies - one was green, the other
flew to the right’. Meaning you’re confusing/mixing two things. Lack of
message boundaries has nothing to do with communication being
asynchronous.
UDP has message boundaries, being asynchronous. There are funky protocols
like LAPD-over-UDP for people who don’t want boundary-lessness of TCP but
need reliability (so they can’t use plain UDP).
This was kind of my point. TCP/IP can get complicated. I don’t have to add
additional code to help mitigate the boundary-lessness of TCP/IP with QNX
low level message passing and QNET. Again, I’m speaking from an embedded
perspective here…
It would take me too long to go into specifics, but this is more
of a personal issue, I just don’t like it (so yeah…I’ll find its
problems!).Woa, finally here comes a statement that can be called accurate >
It was just for you
As with UNIX domain sockets, they don’t work in the network case (i.e.
you
can’t find them across the network).You can use AF_INET domain for network/local communication and AF_UNIX for
local, whichever suits you. UNIX domain has some distinct advantage for
local communications. Better security for example. In both cases you use
very much the same API (sockets).
Again…this was my point. I don’t have to do any of this in the QNX case.
It is the same, regarless of a local or remote case.
You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.Connecting to a remote server over IP has nothing to do with DNS. DNS is a
name resolution service, which is merely a convinience and is not required
for communications at all. And if you’re uncomfortable with port numbers,
what stops you from defining a service name and then translating it into a
port using getservicebyname()?
It does if you don’t know on which server the service resides. This is what
I mean by a distributed environment. A client that doesn’t know where the
service is can be useful. But if you have to hard code everything, then it
makes a design less flexible. So yeah…you have DNS, but you still have to
resolve a service to a port address. Which means you have to assign one,
which means problems if you have to move it. It’s just that it can be
pain. I don’t have to worry about it with QNET stuff…that’s why I like
to use it.
I am reluctant to ask also if you perhaps heard of RPC which makes the
whole
thing more or less transparent (you can make remote function calls).
Yeah…I know about RPC, but there is a lot of stuff between the client and
server to make it work…which means a lot of stuff that can go wrong. For
an embedded application, it doesn’t make a lot of sense for me to use it.
On the other hand, QNX low level messge passing , the resource manager
framework and QNET allow you can write an app and have it communicate
over
the network or in the local case w/o programming changes.Ughm… Cough… cough… cough. Right. Only there’s no global name
service.
Sure there is, it’s called the pathname space, and it works, I use it.
And you can’t send remote pulses (not until 6.2.1). Don’t get me wrong, I
don’t want to just diss QNX messaging. It has its use. However picturing
it
as superior to IP is wishful zealous thinking.
For my uses, it is because it is smaller, easier to use. It takes a lot of
stuff to make IP do what QNET can with regards to the whole QNX node
transparency thing. While TCP/IP is very reliable, it takes a lot of work
to make it do the things I enjoy using with QNET.
On the contrary, synchronous
IPC design does not lend well to networked designs at all, simply because
network medium in most cases is neither deterministic, nor reliable
(granted, when there is a suitable medium, QNX IPC would be better for
realtime communications, but I somehow doubt that is the case implied
here).
Actually it is… That is what I mean. Further more, with switch
ethernet, things are more deterministic, although there are still problems.
Still for ease of use and much simpler implementation of network
communciation, QNET is nice.
It isn’t hard to make things work using an unreliable medium (i.e. radio
modems) with QNET, and because I don’t have to add yet another layer (i.e.
PPP) I am able to use its limited bandwidth more efficently, and it’s one
less thing to debug.
There’s nothing more annoying in real life than clients, which hang
indefinitely on requests that are not going to be answered. Gets twice as
annoying when you also can’t even kill them (which happens a lot in QNX
case).
I had problems with this at first (6.1) but they seem to have gone away.
…snip…
Wanna have a wager on speed of a file copy using QNET and TCP? How much
you
wanna bet?
The speed of QNET isn’t reflected in using cp. You don’t have control over
the message size. A more accurate test would be using a socket compared to
MsgSend() with the same message size. Further more, file copying use TCP/IP
means you are using some network file system, which I’m sure has code to
optimize the data transfer…add that kind of layer between the you and the
node you are transfering the file to under QNET and I bet you’d see
otherwise.
…snip…
BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve for
new
programmers on a project, but give me a break…how hard is QNX message
passing compared to TCP/IP? And just how much time would a new
developer
have to spend learning this stuff in order to be productive? I mean,
really…the hardest thing about the resource manager framework for me
were
the docs, as soon as I had a couple of examples, I was ok. So now, not
only
does the new developer have the docs, he’s got an entire system based on
the
resource manager framekwork, Quelle example!
END RANT:Have you tried to teach a team of 20-30 people of different backgroubds
and
skills level how to use QNX messaging properly? Let alone how to write
resmgrs… You should try.
I don’t work on teams of 20 or 30 people, I work on teams of at most 4 or 5.
20 to 30 is just too big…
Now, “you’ve been Igor’d”.
Nice hearing from you Igor, hope things are going well for you…take care,
-Kevin
– igor (who has 10 years of total QNX experience including 5 with QNX6
and
actually likes it)
“Kevin Stallard” <kevin@fffflyingrobbbotsss.com> wrote in message
news:b9dld1$rnn$1@inn.qnx.com…
Hi Igor,
“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:b9cu0l$1ep$> 1@inn.qnx.com> …
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9cim1$jit$> 1@inn.qnx.com> …
Ron,You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d >
Actually, he was not. You however are about to be. As they sing, ‘you
had
it
coming’… Pop, click, squish, Cicero…Wwwhhhhooooeeee…hang on boys, we’re in for a ride! >
Fasten your seat belts and stop smoking that stuff
Asyncronous messaging isn’t as good as it sounds. If you want
multiple
clients wanting the same data, you have to manage that yourself.Ever heard of multicast?
Yeah, but does the QNX stack support it? And I’m speaking from an
embedded
perspective…it would require a fair amount of additional overhead.
It is supported.
Btw, I am just curious how do you do something like that with QNX messaging?
And what that has to do with being synchronous vs asynchronous…
Also, the
client doesn’t have control over the rate at which the messages are
comming,In synchronous case, clients implicitly do flow control by means of
reply.
In asynchronous case either buffering or protocol-level flow control
(e.g.,
TCP) takes care of that.I didn’t mean flow control. I was referring to applications that need to
know just how fast data is arriving, or that don’t need data at the same
rate as other applicatons. Digital filters need to know how fast data is
arriving. It is useful to have this. It is a pain to implement it on the
server side of a server that takes the initiative of sending the data…
I don’t understand what you mean at all. It must be too early for me
How else do you control the rate at which data is coming if not by flow
control? And how do you ‘know’ that rate when you use QNX messaging?
Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a programmer
has
struggled with the continious nature of data arriving with regards to
state
behavior.As russian saying goes, ‘there flew two flies - one was green, the other
flew to the right’. Meaning you’re confusing/mixing two things. Lack of
message boundaries has nothing to do with communication being
asynchronous.
UDP has message boundaries, being asynchronous. There are funky
protocols
like LAPD-over-UDP for people who don’t want boundary-lessness of TCP
but
need reliability (so they can’t use plain UDP).This was kind of my point. TCP/IP can get complicated. I don’t have to
add
Well haven’t you just ranted about how easy it is to learn stuff? So how
hard it is to learn to use TCP/IP? Beyond being able to select stream or
packet-oriented mode of operation, it is not that much different from coding
perspective…
additional code to help mitigate the boundary-lessness of TCP/IP with QNX
low level message passing and QNET. Again, I’m speaking from an embedded
perspective here…
What’s there to ‘mitigate’? In most cases you can simply stuff a header into
all your messages and use it to define message boundaries on the application
protocol level (vs transport level, like with QNX messaging or UDP). You
usually have to stuff a header into QNX messages as well.
As with UNIX domain sockets, they don’t work in the network case (i.e.
you
can’t find them across the network).You can use AF_INET domain for network/local communication and AF_UNIX
for
local, whichever suits you. UNIX domain has some distinct advantage for
local communications. Better security for example. In both cases you use
very much the same API (sockets).Again…this was my point. I don’t have to do any of this in the QNX
case.
It is the same, regarless of a local or remote case.
And it was my point too. AF_INET code will work for both local and remote.
Having choice of AF_UNIX does not make things worse, does it?
You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.Connecting to a remote server over IP has nothing to do with DNS. DNS is
a
name resolution service, which is merely a convinience and is not
required
for communications at all. And if you’re uncomfortable with port
numbers,
what stops you from defining a service name and then translating it into
a
port using getservicebyname()?It does if you don’t know on which server the service resides. This is
what
I mean by a distributed environment.
Right. Too bad this does not actually work with QNET. It worked in QNX4, but
they never bothered to implement it for QNX6, AFAIK.
A client that doesn’t know where the
service is can be useful.
And equally dangerous. Ever thought of security implications? Who’s the guy
you’re talking to, huh? Is he really who you think he is? By ‘distributed
environment’ you actually mean a bunch of ‘tightly coupled’ nodes with no
security between them. Which is simply not the case for most real-life
distrubuted environments.
You also obviously mean ‘homogenous network’ because the whole network
transparency thing simply does not work for nodes with different endianness.
That is a limitation of the resmgr layer, rather than QNET per say but who
cares who’s limitation it is?
But if you have to hard code everything, then it
makes a design less flexible. So yeah…you have DNS, but you still have
to
resolve a service to a port address. Which means you have to assign one,
which means problems if you have to move it.
You totally lost me again. DNS in classical sense does not tell you where
the service is. It tells you how to translate a name into IP. The word
‘service’ is not related to IP really, it is usually associated with port
number. And you don’t use DNS to find out port numbers. You use
/etc/services and getservicebyname(). Of course you have to assign a name,
but don’t you have to do that with QNX messaging?
OTOH, there are ways to use DNS to do something neat. DNS can resolve a name
to one of a pool of IPs, randomly so that you distribute the load
transparently between identical servers. There’s nothing like that for QNET.
I am reluctant to ask also if you perhaps heard of RPC which makes the
whole
thing more or less transparent (you can make remote function calls).Yeah…I know about RPC, but there is a lot of stuff between the client
and
server to make it work…which means a lot of stuff that can go wrong.
For
an embedded application, it doesn’t make a lot of sense for me to use it.
Actually it means less stuff can go wrong. RPC effectively encapsulates all
the protocol-level work from network application designers (including
endianess issues, mind you). That alone will shave off 80% of complexity in
networked design and practically eliminate communication-level bugs. There’s
a reason why NFS has been implemented that way.
On the other hand, QNX low level messge passing , the resource manager
framework and QNET allow you can write an app and have it communicate
over
the network or in the local case w/o programming changes.Ughm… Cough… cough… cough. Right. Only there’s no global name
service.Sure there is, it’s called the pathname space, and it works, I use it.
Well that would be some news. Last time I checked, the namespace was not
GLOBAL across multiple nodes. Am I wrong?
And you can’t send remote pulses (not until 6.2.1). Don’t get me wrong,
I
don’t want to just diss QNX messaging. It has its use. However picturing
it
as superior to IP is wishful zealous thinking.For my uses, it is because it is smaller, easier to use. It takes a lot
of
stuff to make IP do what QNET can with regards to the whole QNX node
transparency thing. While TCP/IP is very reliable, it takes a lot of work
to make it do the things I enjoy using with QNET.
Practical applicability of the ‘node transparency’ thing is quite overvalued
by QNX fans. Sure, it is neat, but so what? How exactly it is something that
you can ‘sell’ to your customers? They generally don’t care about geek stuff
like that, do they? Unless it creates security issues (see below) and then
they don’t want it at all.
And about difficulty of implementing it with IP… we have networking setup
@ work where all NFS shares get automounted on all other machines under
/net/<machine_name-or-IP_address>. Works like a charm and every node can
actually control what portion of its namespace it wants to publish, to which
clients and with what permissions. Unlike QNET, where it is ‘everything or
nothing’ and a root on any node can easily get root access for every other
node.
The only real advantage QNX networking has when it is used for realtime
communications over a suitable bus, such as CAN or another fieldbus or some
kind of deterministic network like Arcnet. The reason is, for realtime
communication deterministic responce time is much more important than the
bandwidth considerations, so you actually want to avoid buffering. QNX4
native networking was popular for this reason in industrial environments
that used Arcnet and various fieldbuses, until QSSL essentially abandoned
that market quite to dismay of its supporters. QNX6 is apparently starting
to reap those benefits now in the automotive designs, where CAN networks are
becoming popular to tie various components together. I am glad they found
some good use for their networking technology, but that’s definitely a
tightly coupled system, rather than a ‘distributed environment’ in general
sense.
On the contrary, synchronous
IPC design does not lend well to networked designs at all, simply
because
network medium in most cases is neither deterministic, nor reliable
(granted, when there is a suitable medium, QNX IPC would be better for
realtime communications, but I somehow doubt that is the case implied
here).Actually it is…>
The case implied here is Ron’s, not yours, so it is up to him to say that
That is what I mean. Further more, with switch
ethernet, things are more deterministic, although there are still
problems.
Still for ease of use and much simpler implementation of network
communciation, QNET is nice.It isn’t hard to make things work using an unreliable medium (i.e. radio
modems) with QNET, and because I don’t have to add yet another layer (i.e.
PPP) I am able to use its limited bandwidth more efficently, and it’s one
less thing to debug.
You’ve missed the point. Sure, it can be ‘made to work’. However you still
can lose replies, which means you still gonna have [unkillable] clients
indefinitely blocked on remote servers. I don’t actually know how to kill
such clients in networked case. In the local case the only way is to kill
the server… I just hope that would not be the case for networked scenario
And… see below about the bandwidth issue.
There’s nothing more annoying in real life than clients, which hang
indefinitely on requests that are not going to be answered. Gets twice
as
annoying when you also can’t even kill them (which happens a lot in QNX
case).I had problems with this at first (6.1) but they seem to have gone away.
They are still there in 6.2. Have to find out about 6.2.1 yet…
…snip…
Wanna have a wager on speed of a file copy using QNET and TCP? How much
you
wanna bet?The speed of QNET isn’t reflected in using cp. You don’t have control
over
the message size. A more accurate test would be using a socket compared
to
MsgSend() with the same message size. Further more, file copying use
TCP/IP
means you are using some network file system, which I’m sure has code to
optimize the data transfer…add that kind of layer between the you and
the
node you are transfering the file to under QNET and I bet you’d see
otherwise.
LOL. Now you’re talking… So you kinda have to add something to the QNET to
copy files efficiently, huh? And we thought QNET has nice ‘node
transparentcy’ that makes everything simple, bandwidth-efficient, etc and
TCP/IP was complicated and wasteful, no?
Btw, copying a file does not neccessary means network file system. It can
mean FTP or RCP or SSH for example. And actually even if you just send large
amount of data (not one packet) over a socket and over QNET using
ethernet-size packets, you still might find socket being faster. The reason
is, a reply for every damned packet does not have to fly over the damned
wire. The local stack gives you reply on each node, buffers the data and
then uses more suitable protocol to pass it over the wire to the remote
stack. That I think saves more network bandwidth than is being spent on
TCP/IP headers overhead so in the end you might waste more bandwidth with
QNET actually.
Even then, sockets could have been faster yet, if they weren’t based on QNX
IPC at all. Having to reply every damned packet even locally hurts
performance due to excessive context switches. And FYI, they know about it
and AFAIK are planning to do something about it (shhh!!! don’t tell
anyone!!!).
…snip…
BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve for
new
programmers on a project, but give me a break…how hard is QNX
message
passing compared to TCP/IP? And just how much time would a new
developer
have to spend learning this stuff in order to be productive? I mean,
really…the hardest thing about the resource manager framework for me
were
the docs, as soon as I had a couple of examples, I was ok. So now,
not
only
does the new developer have the docs, he’s got an entire system based
on
the
resource manager framekwork, Quelle example!
END RANT:Have you tried to teach a team of 20-30 people of different backgroubds
and
skills level how to use QNX messaging properly? Let alone how to write
resmgrs… You should try.I don’t work on teams of 20 or 30 people, I work on teams of at most 4 or
5.
20 to 30 is just too big…
It is quite enlightening experience, believe me.
Now, “you’ve been Igor’d”.
Nice hearing from you Igor, hope things are going well for you…take
care,
Thanks Kevin. At least you’re taking it like a man, unlike some people did
in the past
Regards,
– igor
Wow! This is a great discussion.
What I get out of it is that TCP/IP is more standard, more widespread,
and can be used by the many programmers who do not understand QNX.
Message passing is easier to write, easier to debug, and easier to
synchronize tasks.
Could this explain why Igor has a team of 30 and Kevin gets by with 6
people? (SORRY - I couldn’t resist ).
Igor Kovalenko wrote:
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9dld1$rnn$> 1@inn.qnx.com> …
Hi Igor,“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:b9cu0l$1ep$> 1@inn.qnx.com> …
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9cim1$jit$> 1@inn.qnx.com> …
Ron,You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d >
Actually, he was not. You however are about to be. As they sing, ‘you
had
it
coming’… Pop, click, squish, Cicero…Wwwhhhhooooeeee…hang on boys, we’re in for a ride! >
Fasten your seat belts and stop smoking that stuff >
Asyncronous messaging isn’t as good as it sounds. If you want
multiple
clients wanting the same data, you have to manage that yourself.Ever heard of multicast?
Yeah, but does the QNX stack support it? And I’m speaking from an
embedded
perspective…it would require a fair amount of additional overhead.
It is supported.
Btw, I am just curious how do you do something like that with QNX messaging?
And what that has to do with being synchronous vs asynchronous…
Also, the
client doesn’t have control over the rate at which the messages are
comming,In synchronous case, clients implicitly do flow control by means of
reply.
In asynchronous case either buffering or protocol-level flow control
(e.g.,
TCP) takes care of that.I didn’t mean flow control. I was referring to applications that need to
know just how fast data is arriving, or that don’t need data at the same
rate as other applicatons. Digital filters need to know how fast data is
arriving. It is useful to have this. It is a pain to implement it on the
server side of a server that takes the initiative of sending the data…
I don’t understand what you mean at all. It must be too early for me >
How else do you control the rate at which data is coming if not by flow
control? And how do you ‘know’ that rate when you use QNX messaging?
Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a programmer
has
struggled with the continious nature of data arriving with regards to
state
behavior.As russian saying goes, ‘there flew two flies - one was green, the other
flew to the right’. Meaning you’re confusing/mixing two things. Lack of
message boundaries has nothing to do with communication being
asynchronous.
UDP has message boundaries, being asynchronous. There are funky
protocols
like LAPD-over-UDP for people who don’t want boundary-lessness of TCP
but
need reliability (so they can’t use plain UDP).This was kind of my point. TCP/IP can get complicated. I don’t have to
add
Well haven’t you just ranted about how easy it is to learn stuff? So how
hard it is to learn to use TCP/IP? Beyond being able to select stream or
packet-oriented mode of operation, it is not that much different from coding
perspective…
additional code to help mitigate the boundary-lessness of TCP/IP with QNX
low level message passing and QNET. Again, I’m speaking from an embedded
perspective here…
What’s there to ‘mitigate’? In most cases you can simply stuff a header into
all your messages and use it to define message boundaries on the application
protocol level (vs transport level, like with QNX messaging or UDP). You
usually have to stuff a header into QNX messages as well.
As with UNIX domain sockets, they don’t work in the network case (i.e.
you
can’t find them across the network).You can use AF_INET domain for network/local communication and AF_UNIX
for
local, whichever suits you. UNIX domain has some distinct advantage for
local communications. Better security for example. In both cases you use
very much the same API (sockets).Again…this was my point. I don’t have to do any of this in the QNX
case.
It is the same, regarless of a local or remote case.
And it was my point too. AF_INET code will work for both local and remote.
Having choice of AF_UNIX does not make things worse, does it?
You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.Connecting to a remote server over IP has nothing to do with DNS. DNS is
a
name resolution service, which is merely a convinience and is not
required
for communications at all. And if you’re uncomfortable with port
numbers,
what stops you from defining a service name and then translating it into
a
port using getservicebyname()?It does if you don’t know on which server the service resides. This is
what
I mean by a distributed environment.
Right. Too bad this does not actually work with QNET. It worked in QNX4, but
they never bothered to implement it for QNX6, AFAIK.
A client that doesn’t know where the
service is can be useful.
And equally dangerous. Ever thought of security implications? Who’s the guy
you’re talking to, huh? Is he really who you think he is? By ‘distributed
environment’ you actually mean a bunch of ‘tightly coupled’ nodes with no
security between them. Which is simply not the case for most real-life
distrubuted environments.You also obviously mean ‘homogenous network’ because the whole network
transparency thing simply does not work for nodes with different endianness.
That is a limitation of the resmgr layer, rather than QNET per say but who
cares who’s limitation it is?
But if you have to hard code everything, then it
makes a design less flexible. So yeah…you have DNS, but you still have
to
resolve a service to a port address. Which means you have to assign one,
which means problems if you have to move it.
You totally lost me again. DNS in classical sense does not tell you where
the service is. It tells you how to translate a name into IP. The word
‘service’ is not related to IP really, it is usually associated with port
number. And you don’t use DNS to find out port numbers. You use
/etc/services and getservicebyname(). Of course you have to assign a name,
but don’t you have to do that with QNX messaging?OTOH, there are ways to use DNS to do something neat. DNS can resolve a name
to one of a pool of IPs, randomly so that you distribute the load
transparently between identical servers. There’s nothing like that for QNET.
I am reluctant to ask also if you perhaps heard of RPC which makes the
whole
thing more or less transparent (you can make remote function calls).Yeah…I know about RPC, but there is a lot of stuff between the client
and
server to make it work…which means a lot of stuff that can go wrong.
For
an embedded application, it doesn’t make a lot of sense for me to use it.
Actually it means less stuff can go wrong. RPC effectively encapsulates all
the protocol-level work from network application designers (including
endianess issues, mind you). That alone will shave off 80% of complexity in
networked design and practically eliminate communication-level bugs. There’s
a reason why NFS has been implemented that way.
On the other hand, QNX low level messge passing , the resource manager
framework and QNET allow you can write an app and have it communicate
over
the network or in the local case w/o programming changes.Ughm… Cough… cough… cough. Right. Only there’s no global name
service.Sure there is, it’s called the pathname space, and it works, I use it.
Well that would be some news. Last time I checked, the namespace was not
GLOBAL across multiple nodes. Am I wrong?
And you can’t send remote pulses (not until 6.2.1). Don’t get me wrong,
I
don’t want to just diss QNX messaging. It has its use. However picturing
it
as superior to IP is wishful zealous thinking.For my uses, it is because it is smaller, easier to use. It takes a lot
of
stuff to make IP do what QNET can with regards to the whole QNX node
transparency thing. While TCP/IP is very reliable, it takes a lot of work
to make it do the things I enjoy using with QNET.
Practical applicability of the ‘node transparency’ thing is quite overvalued
by QNX fans. Sure, it is neat, but so what? How exactly it is something that
you can ‘sell’ to your customers? They generally don’t care about geek stuff
like that, do they? Unless it creates security issues (see below) and then
they don’t want it at all.And about difficulty of implementing it with IP… we have networking setup
@ work where all NFS shares get automounted on all other machines under
/net/<machine_name-or-IP_address>. Works like a charm and every node can
actually control what portion of its namespace it wants to publish, to which
clients and with what permissions. Unlike QNET, where it is ‘everything or
nothing’ and a root on any node can easily get root access for every other
node.The only real advantage QNX networking has when it is used for realtime
communications over a suitable bus, such as CAN or another fieldbus or some
kind of deterministic network like Arcnet. The reason is, for realtime
communication deterministic responce time is much more important than the
bandwidth considerations, so you actually want to avoid buffering. QNX4
native networking was popular for this reason in industrial environments
that used Arcnet and various fieldbuses, until QSSL essentially abandoned
that market quite to dismay of its supporters. QNX6 is apparently starting
to reap those benefits now in the automotive designs, where CAN networks are
becoming popular to tie various components together. I am glad they found
some good use for their networking technology, but that’s definitely a
tightly coupled system, rather than a ‘distributed environment’ in general
sense.
On the contrary, synchronous
IPC design does not lend well to networked designs at all, simply
because
network medium in most cases is neither deterministic, nor reliable
(granted, when there is a suitable medium, QNX IPC would be better for
realtime communications, but I somehow doubt that is the case implied
here).Actually it is…>
The case implied here is Ron’s, not yours, so it is up to him to say that >
That is what I mean. Further more, with switch
ethernet, things are more deterministic, although there are still
problems.
Still for ease of use and much simpler implementation of network
communciation, QNET is nice.It isn’t hard to make things work using an unreliable medium (i.e. radio
modems) with QNET, and because I don’t have to add yet another layer (i.e.
PPP) I am able to use its limited bandwidth more efficently, and it’s one
less thing to debug.
You’ve missed the point. Sure, it can be ‘made to work’. However you still
can lose replies, which means you still gonna have [unkillable] clients
indefinitely blocked on remote servers. I don’t actually know how to kill
such clients in networked case. In the local case the only way is to kill
the server… I just hope that would not be the case for networked scenario
And… see below about the bandwidth issue.
There’s nothing more annoying in real life than clients, which hang
indefinitely on requests that are not going to be answered. Gets twice
as
annoying when you also can’t even kill them (which happens a lot in QNX
case).I had problems with this at first (6.1) but they seem to have gone away.
They are still there in 6.2. Have to find out about 6.2.1 yet…
…snip…Wanna have a wager on speed of a file copy using QNET and TCP? How much
you
wanna bet?The speed of QNET isn’t reflected in using cp. You don’t have control
over
the message size. A more accurate test would be using a socket compared
to
MsgSend() with the same message size. Further more, file copying use
TCP/IP
means you are using some network file system, which I’m sure has code to
optimize the data transfer…add that kind of layer between the you and
the
node you are transfering the file to under QNET and I bet you’d see
otherwise.
LOL. Now you’re talking… So you kinda have to add something to the QNET to
copy files efficiently, huh? And we thought QNET has nice ‘node
transparentcy’ that makes everything simple, bandwidth-efficient, etc and
TCP/IP was complicated and wasteful, no?Btw, copying a file does not neccessary means network file system. It can
mean FTP or RCP or SSH for example. And actually even if you just send large
amount of data (not one packet) over a socket and over QNET using
ethernet-size packets, you still might find socket being faster. The reason
is, a reply for every damned packet does not have to fly over the damned
wire. The local stack gives you reply on each node, buffers the data and
then uses more suitable protocol to pass it over the wire to the remote
stack. That I think saves more network bandwidth than is being spent on
TCP/IP headers overhead so in the end you might waste more bandwidth with
QNET actually.Even then, sockets could have been faster yet, if they weren’t based on QNX
IPC at all. Having to reply every damned packet even locally hurts
performance due to excessive context switches. And FYI, they know about it
and AFAIK are planning to do something about it (shhh!!! don’t tell
anyone!!!).
…snip…BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve for
new
programmers on a project, but give me a break…how hard is QNX
message
passing compared to TCP/IP? And just how much time would a new
developer
have to spend learning this stuff in order to be productive? I mean,
really…the hardest thing about the resource manager framework for me
were
the docs, as soon as I had a couple of examples, I was ok. So now,
not
only
does the new developer have the docs, he’s got an entire system based
on
the
resource manager framekwork, Quelle example!
END RANT:Have you tried to teach a team of 20-30 people of different backgroubds
and
skills level how to use QNX messaging properly? Let alone how to write
resmgrs… You should try.I don’t work on teams of 20 or 30 people, I work on teams of at most 4 or
5.
20 to 30 is just too big…
It is quite enlightening experience, believe me.
Now, “you’ve been Igor’d”.Nice hearing from you Igor, hope things are going well for you…take
care,
Thanks Kevin. At least you’re taking it like a man, unlike some people did
in the past >Regards,
– igor
–
John Halpenny
Natural Resources Canada Ressources Naturelles Canada
Geodetic Survey Division Division des levés géodésiques
615 Booth St., Room 498H 615 rue Booth, Pièce 498H
Ottawa, Ontario, Canada
K1A-0E9
Phone: (613) 996-9321
“John Halpenny” <jhalpenn@nrcan.gc.ca> wrote in message
news:3EBA9AD6.78DEAFF7@nrcan.gc.ca…
Wow! This is a great discussion.
Indeed.
What I get out of it is that TCP/IP is more standard, more widespread,
and can be used by the many programmers who do not understand QNX.
Message passing is easier to write, easier to debug, and easier to
synchronize tasks.
Actually that’s kinda skewed impression. The main point was that TCP/IP is
better suited to generic (non-realtime) networking. It also promotes certain
level of protocol discipline that lends to more robust real-life
communications than QNET (which crucially depends on reliable replies and
hence is prone to lockups). They are about equally easy to write, but TCP/IP
is actually much easier to debug. TCP/IP also has more features and
optimisations, which you’d have to do yourself with QNET if you need them.
Could this explain why Igor has a team of 30 and Kevin gets by with 6
people? (SORRY - I couldn’t resist >
Igor does not have a team. Igor is part of a team
You might want to consider the scope of the projects, before you jump to
conclusions. Not everything can be done with 6 people.
By the way, we use both QNX messaging and TCP/IP.
– igor
Igor Kovalenko wrote:
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9dld1$rnn$> 1@inn.qnx.com> …
Hi Igor,“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:b9cu0l$1ep$> 1@inn.qnx.com> …
“Kevin Stallard” <> kevin@fffflyingrobbbotsss.com> > wrote in message
news:b9cim1$jit$> 1@inn.qnx.com> …
Ron,You’ve just had a rare and very distinguished honor placed upon
you…you’ve been Igor’d >
Actually, he was not. You however are about to be. As they sing,
‘you
had
it
coming’… Pop, click, squish, Cicero…Wwwhhhhooooeeee…hang on boys, we’re in for a ride! >
Fasten your seat belts and stop smoking that stuff >
Asyncronous messaging isn’t as good as it sounds. If you want
multiple
clients wanting the same data, you have to manage that yourself.Ever heard of multicast?
Yeah, but does the QNX stack support it? And I’m speaking from an
embedded
perspective…it would require a fair amount of additional overhead.
It is supported.
Btw, I am just curious how do you do something like that with QNX
messaging?
And what that has to do with being synchronous vs asynchronous…
Also, the
client doesn’t have control over the rate at which the messages
are
comming,In synchronous case, clients implicitly do flow control by means of
reply.
In asynchronous case either buffering or protocol-level flow control
(e.g.,
TCP) takes care of that.I didn’t mean flow control. I was referring to applications that need
to
know just how fast data is arriving, or that don’t need data at the
same
rate as other applicatons. Digital filters need to know how fast data
is
arriving. It is useful to have this. It is a pain to implement it on
the
server side of a server that takes the initiative of sending the
data…
I don’t understand what you mean at all. It must be too early for me >
How else do you control the rate at which data is coming if not by flow
control? And how do you ‘know’ that rate when you use QNX messaging?
Further more, asyncronous is fine for me if it’s streaming audio,
but for more critical things…I’ve seen an example where a
programmer
has
struggled with the continious nature of data arriving with regards
to
state
behavior.As russian saying goes, ‘there flew two flies - one was green, the
other
flew to the right’. Meaning you’re confusing/mixing two things. Lack
of
message boundaries has nothing to do with communication being
asynchronous.
UDP has message boundaries, being asynchronous. There are funky
protocols
like LAPD-over-UDP for people who don’t want boundary-lessness of
TCP
but
need reliability (so they can’t use plain UDP).This was kind of my point. TCP/IP can get complicated. I don’t have
to
add
Well haven’t you just ranted about how easy it is to learn stuff? So how
hard it is to learn to use TCP/IP? Beyond being able to select stream or
packet-oriented mode of operation, it is not that much different from
coding
perspective…
additional code to help mitigate the boundary-lessness of TCP/IP with
QNX
low level message passing and QNET. Again, I’m speaking from an
embedded
perspective here…
What’s there to ‘mitigate’? In most cases you can simply stuff a header
into
all your messages and use it to define message boundaries on the
application
protocol level (vs transport level, like with QNX messaging or UDP). You
usually have to stuff a header into QNX messages as well.
As with UNIX domain sockets, they don’t work in the network case
(i.e.
you
can’t find them across the network).You can use AF_INET domain for network/local communication and
AF_UNIX
for
local, whichever suits you. UNIX domain has some distinct advantage
for
local communications. Better security for example. In both cases you
use
very much the same API (sockets).Again…this was my point. I don’t have to do any of this in the QNX
case.
It is the same, regarless of a local or remote case.
And it was my point too. AF_INET code will work for both local and
remote.
Having choice of AF_UNIX does not make things worse, does it?
You have would have to use DNS and
know the port to which you need to connect. It’s just a lot more
complicated.Connecting to a remote server over IP has nothing to do with DNS.
DNS is
a
name resolution service, which is merely a convinience and is not
required
for communications at all. And if you’re uncomfortable with port
numbers,
what stops you from defining a service name and then translating it
into
a
port using getservicebyname()?It does if you don’t know on which server the service resides. This
is
what
I mean by a distributed environment.
Right. Too bad this does not actually work with QNET. It worked in QNX4,
but
they never bothered to implement it for QNX6, AFAIK.
A client that doesn’t know where the
service is can be useful.
And equally dangerous. Ever thought of security implications? Who’s the
guy
you’re talking to, huh? Is he really who you think he is? By
‘distributed
environment’ you actually mean a bunch of ‘tightly coupled’ nodes with
no
security between them. Which is simply not the case for most real-life
distrubuted environments.You also obviously mean ‘homogenous network’ because the whole network
transparency thing simply does not work for nodes with different
endianness.
That is a limitation of the resmgr layer, rather than QNET per say but
who
cares who’s limitation it is?
But if you have to hard code everything, then it
makes a design less flexible. So yeah…you have DNS, but you still
have
to
resolve a service to a port address. Which means you have to assign
one,
which means problems if you have to move it.
You totally lost me again. DNS in classical sense does not tell you
where
the service is. It tells you how to translate a name into IP. The word
‘service’ is not related to IP really, it is usually associated with
port
number. And you don’t use DNS to find out port numbers. You use
/etc/services and getservicebyname(). Of course you have to assign a
name,
but don’t you have to do that with QNX messaging?OTOH, there are ways to use DNS to do something neat. DNS can resolve a
name
to one of a pool of IPs, randomly so that you distribute the load
transparently between identical servers. There’s nothing like that for
QNET.
I am reluctant to ask also if you perhaps heard of RPC which makes
the
whole
thing more or less transparent (you can make remote function calls).Yeah…I know about RPC, but there is a lot of stuff between the
client
and
server to make it work…which means a lot of stuff that can go wrong.
For
an embedded application, it doesn’t make a lot of sense for me to use
it.
Actually it means less stuff can go wrong. RPC effectively encapsulates
all
the protocol-level work from network application designers (including
endianess issues, mind you). That alone will shave off 80% of complexity
in
networked design and practically eliminate communication-level bugs.
There’s
a reason why NFS has been implemented that way.
On the other hand, QNX low level messge passing , the resource
manager
framework and QNET allow you can write an app and have it
communicate
over
the network or in the local case w/o programming changes.Ughm… Cough… cough… cough. Right. Only there’s no global name
service.Sure there is, it’s called the pathname space, and it works, I use it.
Well that would be some news. Last time I checked, the namespace was not
GLOBAL across multiple nodes. Am I wrong?
And you can’t send remote pulses (not until 6.2.1). Don’t get me
wrong,
I
don’t want to just diss QNX messaging. It has its use. However
picturing
it
as superior to IP is wishful zealous thinking.For my uses, it is because it is smaller, easier to use. It takes a
lot
of
stuff to make IP do what QNET can with regards to the whole QNX node
transparency thing. While TCP/IP is very reliable, it takes a lot of
work
to make it do the things I enjoy using with QNET.
Practical applicability of the ‘node transparency’ thing is quite
overvalued
by QNX fans. Sure, it is neat, but so what? How exactly it is something
that
you can ‘sell’ to your customers? They generally don’t care about geek
stuff
like that, do they? Unless it creates security issues (see below) and
then
they don’t want it at all.And about difficulty of implementing it with IP… we have networking
setup
@ work where all NFS shares get automounted on all other machines under
/net/<machine_name-or-IP_address>. Works like a charm and every node can
actually control what portion of its namespace it wants to publish, to
which
clients and with what permissions. Unlike QNET, where it is ‘everything
or
nothing’ and a root on any node can easily get root access for every
other
node.The only real advantage QNX networking has when it is used for realtime
communications over a suitable bus, such as CAN or another fieldbus or
some
kind of deterministic network like Arcnet. The reason is, for realtime
communication deterministic responce time is much more important than
the
bandwidth considerations, so you actually want to avoid buffering. QNX4
native networking was popular for this reason in industrial environments
that used Arcnet and various fieldbuses, until QSSL essentially
abandoned
that market quite to dismay of its supporters. QNX6 is apparently
starting
to reap those benefits now in the automotive designs, where CAN networks
are
becoming popular to tie various components together. I am glad they
found
some good use for their networking technology, but that’s definitely a
tightly coupled system, rather than a ‘distributed environment’ in
general
sense.
On the contrary, synchronous
IPC design does not lend well to networked designs at all, simply
because
network medium in most cases is neither deterministic, nor reliable
(granted, when there is a suitable medium, QNX IPC would be better
for
realtime communications, but I somehow doubt that is the case
implied
here).Actually it is…>
The case implied here is Ron’s, not yours, so it is up to him to say
that >
That is what I mean. Further more, with switch
ethernet, things are more deterministic, although there are still
problems.
Still for ease of use and much simpler implementation of network
communciation, QNET is nice.It isn’t hard to make things work using an unreliable medium (i.e.
radio
modems) with QNET, and because I don’t have to add yet another layer
(i.e.
PPP) I am able to use its limited bandwidth more efficently, and it’s
one
less thing to debug.
You’ve missed the point. Sure, it can be ‘made to work’. However you
still
can lose replies, which means you still gonna have [unkillable] clients
indefinitely blocked on remote servers. I don’t actually know how to
kill
such clients in networked case. In the local case the only way is to
kill
the server… I just hope that would not be the case for networked
scenario
And… see below about the bandwidth issue.
There’s nothing more annoying in real life than clients, which hang
indefinitely on requests that are not going to be answered. Gets
twice
as
annoying when you also can’t even kill them (which happens a lot in
QNX
case).I had problems with this at first (6.1) but they seem to have gone
away.
They are still there in 6.2. Have to find out about 6.2.1 yet…
…snip…Wanna have a wager on speed of a file copy using QNET and TCP? How
much
you
wanna bet?The speed of QNET isn’t reflected in using cp. You don’t have control
over
the message size. A more accurate test would be using a socket
compared
to
MsgSend() with the same message size. Further more, file copying use
TCP/IP
means you are using some network file system, which I’m sure has code
to
optimize the data transfer…add that kind of layer between the you
and
the
node you are transfering the file to under QNET and I bet you’d see
otherwise.
LOL. Now you’re talking… So you kinda have to add something to the
QNET to
copy files efficiently, huh? And we thought QNET has nice ‘node
transparentcy’ that makes everything simple, bandwidth-efficient, etc
and
TCP/IP was complicated and wasteful, no?Btw, copying a file does not neccessary means network file system. It
can
mean FTP or RCP or SSH for example. And actually even if you just send
large
amount of data (not one packet) over a socket and over QNET using
ethernet-size packets, you still might find socket being faster. The
reason
is, a reply for every damned packet does not have to fly over the damned
wire. The local stack gives you reply on each node, buffers the data and
then uses more suitable protocol to pass it over the wire to the remote
stack. That I think saves more network bandwidth than is being spent on
TCP/IP headers overhead so in the end you might waste more bandwidth
with
QNET actually.Even then, sockets could have been faster yet, if they weren’t based on
QNX
IPC at all. Having to reply every damned packet even locally hurts
performance due to excessive context switches. And FYI, they know about
it
and AFAIK are planning to do something about it (shhh!!! don’t tell
anyone!!!).
…snip…BEGIN RANT:
Ok…ok…there is the notion that there would be a learning curve
for
new
programmers on a project, but give me a break…how hard is QNX
message
passing compared to TCP/IP? And just how much time would a new
developer
have to spend learning this stuff in order to be productive? I
mean,
really…the hardest thing about the resource manager framework
for me
were
the docs, as soon as I had a couple of examples, I was ok. So
now,
not
only
does the new developer have the docs, he’s got an entire system
based
on
the
resource manager framekwork, Quelle example!
END RANT:Have you tried to teach a team of 20-30 people of different
backgroubds
and
skills level how to use QNX messaging properly? Let alone how to
write
resmgrs… You should try.I don’t work on teams of 20 or 30 people, I work on teams of at most 4
or
5.
20 to 30 is just too big…
It is quite enlightening experience, believe me.
Now, “you’ve been Igor’d”.Nice hearing from you Igor, hope things are going well for you…take
care,
Thanks Kevin. At least you’re taking it like a man, unlike some people
did
in the past >Regards,
– igor–
John HalpennyNatural Resources Canada Ressources Naturelles Canada
Geodetic Survey Division Division des levés géodésiques
615 Booth St., Room 498H 615 rue Booth, Pièce 498H
Ottawa, Ontario, Canada
K1A-0E9
Phone: (613) 996-9321
One needs to decide what is important to oneself when choosing a
method. If portability (to other OSes) is an issue then definitely
stay away from QNX IPC (message passing).
If size & speed efficiency is an issue then I’d lean toward QNX IPC.
TCP/IP is built on top of QNX IPC. So it is another layer of fat.
Does that extra layer buy you anything? Yes! But is what it buys you
importnt to you? That you have to decide.
As for me, I have the luxery of working exclusively with QNX. So I
don’t have to interface to (or port to) any other system. So I use
the QNX IPC. I do however write my own cover functions to the QNX
methods that make them easier for me to use. (Yes, an extra layer.
But a thin one.) If I absolutely had to port to some other OS some day,
I would just rewrite those cover functions to take advantage of
whatever that other OS used.
Igor Kovalenko <kovalenko@attbi.com> wrote:
IK > “John Halpenny” <jhalpenn@nrcan.gc.ca> wrote in message
IK > news:3EBA9AD6.78DEAFF7@nrcan.gc.ca…
Wow! This is a great discussion.
IK > Indeed.
What I get out of it is that TCP/IP is more standard, more widespread,
and can be used by the many programmers who do not understand QNX.
Message passing is easier to write, easier to debug, and easier to
synchronize tasks.
IK > Actually that’s kinda skewed impression. The main point was that TCP/IP is
IK > better suited to generic (non-realtime) networking. It also promotes certain
IK > level of protocol discipline that lends to more robust real-life
IK > communications than QNET (which crucially depends on reliable replies and
IK > hence is prone to lockups). They are about equally easy to write, but TCP/IP
IK > is actually much easier to debug. TCP/IP also has more features and
IK > optimisations, which you’d have to do yourself with QNET if you need them.
Could this explain why Igor has a team of 30 and Kevin gets by with 6
people? (SORRY - I couldn’t resist >
IK > Igor does not have a team. Igor is part of a team
IK > You might want to consider the scope of the projects, before you jump to
IK > conclusions. Not everything can be done with 6 people.
IK > By the way, we use both QNX messaging and TCP/IP.
Bill Caroselli wrote:
One needs to decide what is important to oneself when choosing a
method. If portability (to other OSes) is an issue then definitely
stay away from QNX IPC (message passing).If size & speed efficiency is an issue then I’d lean toward QNX IPC.
What bugs me is that I try and try and try, yet still apparently the
message does not get through. What is ‘speed’? Can you define it? Is it
how much data you can pass in a unit of time or is it how fast is
delivery time per packet? How about ‘efficiency’? Is it memory
consumption or CPU usage or network usage or some combination of those?
In the previous replies I explained why, being build on top of QNX IPC,
the TCP/IP can be (and usually is) faster than QNX IPC when you pass
large amount of packets through network. Do I need to repeat that or you
can just read up? If you want to claim that QNX IPC is ‘faster’ and
‘more efficient’, be my guest but this is a technical forum, not
religious. No matter how much faith you have in ‘QNX way’, you have to
substantiate your claim.
TCP/IP is built on top of QNX IPC. So it is another layer of fat.
Does that extra layer buy you anything? Yes! But is what it buys you
importnt to you? That you have to decide.
Can you imagine that fat buys you better network utilization and more
robustness?
As for me, I have the luxery of working exclusively with QNX.
It is the luxury of being oblivious to other technologies. QNX is not
the answer to all problems. You might feel happy, but you don’t know
what you’re missing. Might as well say that a blind man has the luxury
of only using senses other than vision.
So I
don’t have to interface to (or port to) any other system. So I use
the QNX IPC. I do however write my own cover functions to the QNX
methods that make them easier for me to use. (Yes, an extra layer.
But a thin one.) If I absolutely had to port to some other OS some day,
I would just rewrite those cover functions to take advantage of
whatever that other OS used.
That IMHO is quite useless thing. I fail to see a point in writing
non-portable wrappers for non-portable functions. You might as well just
port the non-portable functions themselves. That has been done.
– igor
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
IK > “John Halpenny” <> jhalpenn@nrcan.gc.ca> > wrote in message
IK > news:> 3EBA9AD6.78DEAFF7@nrcan.gc.ca> …Wow! This is a great discussion.
IK > Indeed.
What I get out of it is that TCP/IP is more standard, more widespread,
and can be used by the many programmers who do not understand QNX.
Message passing is easier to write, easier to debug, and easier to
synchronize tasks.
IK > Actually that’s kinda skewed impression. The main point was that TCP/IP is
IK > better suited to generic (non-realtime) networking. It also promotes certain
IK > level of protocol discipline that lends to more robust real-life
IK > communications than QNET (which crucially depends on reliable replies and
IK > hence is prone to lockups). They are about equally easy to write, but TCP/IP
IK > is actually much easier to debug. TCP/IP also has more features and
IK > optimisations, which you’d have to do yourself with QNET if you need them.
Could this explain why Igor has a team of 30 and Kevin gets by with 6
people? (SORRY - I couldn’t resist >
IK > Igor does not have a team. Igor is part of a team >
IK > You might want to consider the scope of the projects, before you jump to
IK > conclusions. Not everything can be done with 6 people.IK > By the way, we use both QNX messaging and TCP/IP.
Ouch! I guess he told me.
Igor Kovalenko <kovalenko@attbi.com> wrote:
IK > Bill Caroselli wrote:
One needs to decide what is important to oneself when choosing a
method. If portability (to other OSes) is an issue then definitely
stay away from QNX IPC (message passing).If size & speed efficiency is an issue then I’d lean toward QNX IPC.
IK > What bugs me is that I try and try and try, yet still apparently the
IK > message does not get through. What is ‘speed’? Can you define it? Is it
IK > how much data you can pass in a unit of time or is it how fast is
IK > delivery time per packet? How about ‘efficiency’? Is it memory
IK > consumption or CPU usage or network usage or some combination of those?
IK > In the previous replies I explained why, being build on top of QNX IPC,
IK > the TCP/IP can be (and usually is) faster than QNX IPC when you pass
IK > large amount of packets through network. Do I need to repeat that or you
IK > can just read up? If you want to claim that QNX IPC is ‘faster’ and
IK > ‘more efficient’, be my guest but this is a technical forum, not
IK > religious. No matter how much faith you have in ‘QNX way’, you have to
IK > substantiate your claim.
TCP/IP is built on top of QNX IPC. So it is another layer of fat.
Does that extra layer buy you anything? Yes! But is what it buys you
importnt to you? That you have to decide.
IK > Can you imagine that fat buys you better network utilization and more
IK > robustness?
As for me, I have the luxery of working exclusively with QNX.
IK > It is the luxury of being oblivious to other technologies. QNX is not
IK > the answer to all problems. You might feel happy, but you don’t know
IK > what you’re missing. Might as well say that a blind man has the luxury
IK > of only using senses other than vision.
So I
don’t have to interface to (or port to) any other system. So I use
the QNX IPC. I do however write my own cover functions to the QNX
methods that make them easier for me to use. (Yes, an extra layer.
But a thin one.) If I absolutely had to port to some other OS some day,
I would just rewrite those cover functions to take advantage of
whatever that other OS used.
IK > That IMHO is quite useless thing. I fail to see a point in writing
IK > non-portable wrappers for non-portable functions. You might as well just
IK > port the non-portable functions themselves. That has been done.
IK > – igor
I was having a rough day, not anymore, you guys just bowl me over in
laughter sometimes (lol).
Regards.
Bill Caroselli <qtps@earthlink.net> wrote:
Ouch! I guess he told me.
Igor Kovalenko <> kovalenko@attbi.com> > wrote:
IK > Bill Caroselli wrote:
One needs to decide what is important to oneself when choosing a
method. If portability (to other OSes) is an issue then definitely
stay away from QNX IPC (message passing).If size & speed efficiency is an issue then I’d lean toward QNX IPC.
IK > What bugs me is that I try and try and try, yet still apparently the
IK > message does not get through. What is ‘speed’? Can you define it? Is it
IK > how much data you can pass in a unit of time or is it how fast is
IK > delivery time per packet? How about ‘efficiency’? Is it memory
IK > consumption or CPU usage or network usage or some combination of those?IK > In the previous replies I explained why, being build on top of QNX IPC,
IK > the TCP/IP can be (and usually is) faster than QNX IPC when you pass
IK > large amount of packets through network. Do I need to repeat that or you
IK > can just read up? If you want to claim that QNX IPC is ‘faster’ and
IK > ‘more efficient’, be my guest but this is a technical forum, not
IK > religious. No matter how much faith you have in ‘QNX way’, you have to
IK > substantiate your claim.TCP/IP is built on top of QNX IPC. So it is another layer of fat.
Does that extra layer buy you anything? Yes! But is what it buys you
importnt to you? That you have to decide.IK > Can you imagine that fat buys you better network utilization and more
IK > robustness?
As for me, I have the luxery of working exclusively with QNX.IK > It is the luxury of being oblivious to other technologies. QNX is not
IK > the answer to all problems. You might feel happy, but you don’t know
IK > what you’re missing. Might as well say that a blind man has the luxury
IK > of only using senses other than vision.So I
don’t have to interface to (or port to) any other system. So I use
the QNX IPC. I do however write my own cover functions to the QNX
methods that make them easier for me to use. (Yes, an extra layer.
But a thin one.) If I absolutely had to port to some other OS some day,
I would just rewrite those cover functions to take advantage of
whatever that other OS used.IK > That IMHO is quite useless thing. I fail to see a point in writing
IK > non-portable wrappers for non-portable functions. You might as well just
IK > port the non-portable functions themselves. That has been done.IK > – igor
Wow, that was a great thread. Thanks for all your comments, they were
quite informative and entertaining! In the end we decided to go the TCP
route even though it’s a proprietary network we’re creating, for many of
the reasons brought up by posters in this thread.
Thanks!
Ron
Ron wrote:
I’ve got a client/server setup and wish to use ConnectAttach() for
message passing. I can’t get the remote PID (on the server) from the
client, although according to Krten in Neutrino 2 all I have to do is
“perform a simple open() of the pathname.” Further references in the
book don’t clarify it (for me anyway). Can anyone help?PS I’m using 6.1
TIA
Ron