Hello all,
is there a possibility to connect to a process on a QNX node from a machine not running QNX and exchange messages? In other words: Has anyone successfully implemented MsgSend(), MsgReceive() and MsgReply() primitives to work over a standard TCP/IP connection instead of QNet so that the original QNX program can be compiled, linked and run under e.g. Windows?
I can think of many applications for such a port.
Regards,
Albrecht
Hello,
thank you for that hint. I was not aware of this project, however, I understand that it enables a group of Linux-Processes to communicate in a QNX-like fashion. I doubt that you can connect to a real QNX process. I will ask.
What I am thinking about is to be able to compile and run a QNX program that uses QNX Message Passing primitives e.g. under Windows.
Regards,
Albrecht
SIMPL doesn’t provide interoperability nor does it provide network services (only local) .
Emulating basic QNX S/R/R with TCP/IP is not that complicated, but it’s when you get into the detail that it can get REALLY hairy. For example: name services (gns), delivering events, notification, queue are just a few. How do you transfer the nid,pid,chid concept to TCP/IP.
Personally I go the other way around, when I want my QNX apps to talk to Windows (or any other OS) I build sets of functions build on TCP/IP for QNX. I prefer to adapt QNX to Windows then Windows to QNX. Otherwise you confuse the heck out of Windows programmers
By the way there is something called PVS or something similar I can’t recall the exact name, that support message passing on most OS. Armin from Steinhoff is a real fan.
SIMPL does provide communication between QNX and Linux as well as WIndows. It does not however allow you to use native message passing directly. You have to use the SIMPL api. It builds S/R/R on top of TCP/IP, and it does have a name service concept. The QNX 4 port, which is unique for SIMPL uses QNX message passing for local transfers. I ported the generic version to QNX 6, which only uses TCP/IP, and I recall it was a fairly easy port. It is not surprising that it doesn’t bridge systems using native message passing. As Mario pointed out, even between QNX 4 and 6 the models are very different. There was at one time a QNX 2/QNX 4 bridge product built by Terry Laughlin and Bill Flowers that I believe hooked in directly. This required proprietary knowledge, and I don’t think it was ever very successful.
Just looked at SIMPL, wow it made some progress since I lasted checked. However there doesn’t seems to be any real distributed name services, you still need to know on what machine the program you want to talk to is.
I looked at the code and you said it ported easy??? Data transfer seems to be based on fifo’s and shared memory? That won’t work cross platform?
Mario, my knowledge at the source code level is limited. I believe there are three somewhat different sets of core code. Unsurprisingly the Windows stuff is different. The QNX 4 version stands out because the there are some local processes that communicate using QNX message passing as the transport mechanism. The Unix/Linux code base also needs this communication, but instead uses TCP/IP, just as it does between nodes. It is this Linux version that I found easy to port to QNX 6.
I think the fifo’s and shared memory you mention are for local “message passing” only. Since (I believe) all this code is Posix conforming, or at least close, it ported without a hitch. Getting it configured right was more trouble, and not all that much either.
Hello,
this is the problem. We have the following situation:
We have a SCADA system comprising of three server processes that handle different parts of the process data and a whole bunch of clients that communicate with one or more of the servers to retrieve a specific subset of the process variables and do a specific job on them. All processes run on QNX, they can be distributed over the network and use gns and name_open() to find the servers. The communication is hidden behind a set of libraries such that writing a client requires little effort.
It would now be very beneficial if we could port existing clients or write new ones on Windows or Linux. Because our system is constrained to QNX, we must rely on things like web servers / HTTP access or Phindows to enable the office world that runs on Windows to communicate to our system.
Although this works technically correctly, it is more and more difficult to explain to the customer why they must use a dedicated computer running QNX to do the design work, among other things, and has also some limitations in what you can do on the remote Non-QNX-client.
Of course we could set up a completely new API to the system based on TCP/IP services but that means changing core aspects which we want to avoid. The servers for instance must be able to receive messages from real QNX processes as before as well as from processes running on remote Windows or Linux hosts.
I think the type of system design we have is fairly common to QNX systems, so maybe other folks have had the same situation already.
Any ideas welcome.
Best regards,
Albrecht
Albrecht,
I can suggest the obvious solution to your problem (obvious in that I am sure you’ve already thought of it).
You could just set up proxy processes/threads on your QNX servers to talk to the remote Windows/Linux client. Those processes/threads would then be able to use native QNX S/R/R calls to communicate with your core code.
The proxy processes would then handle sending/receiving data via TCP/IP to remote Linux/Windows machines. You’d need one manager task running on the servers listening for incoming connections from Windows/Linux hosts and when an incoming connection came, you’d spawn one process (or thread really) to handle that remote connection (and to do the native QNX calls to the core stuff).
The Windows/Linux clients can then find the QNX host by using a hostname and known port so there isn’t any issue finding your servers on the network.
You’d only need to write the connection (proxy) manager task which shouldn’t be very hard.
Tim
Tim,
sure I was already thinking about this. I started this discussion to see if the problem is of general interest and to gather some more ideas.
I think I will try to put a more precise specification together and post it. If anyone is interested to add some comments or suggestions please feel free to do so.
It would also be interesting to know if porting the QNX Message Passing API to another OS (using the proxy processes) can get me into legal trouble. What do you guys think?
Best regards,
Albrecht
Legal trouble? I’ve heard some kind of weird rumor in the past that QNX owned message passing?
Nope!
Mario, searching this item down to the patent claims, I still see no claim to a patent on message passing. The possibly related claim is to
“A method of implementing a distributed operating system”. That method is not itself message passing. I have no opinion on whether this is a valid patent or not, but clearly the original poster is not implementing a distributed operating system and so he could not be infringing.
You may or may not remember, but in the 80’s both Dan and Gorden were up front about the fact that the ideas about the message passing implemented in QNX came from a system called Thoth that they studied in college.
Thinking about the issue, I believe that the VxWorks porting library is technically the same thing: QSSL implemented a proprietary API (Windriver’s) to work on a different OS (QNX Neutrino) for which it was not originally designed. And that seems to be legal. Of course, the difference is that the VxWorks porting library is only meant as a tool to help porting VxWorks applications to QNX Neutrino whereas I want to use the QNX API under Windows or Linux in a production system but I don’t know if that makes a difference in legal terms.
Albrecht
I had one more thought on patents. US patents at least. You cannot patent something after you have disclosed it, even if you are the original inventor. This is a pretty strict rule. If you come up with an idea, go out with your buddies, and over a beer describe it, and the next day you apply for a patent, you are already too late. So pretty much anything learned about QNX message passing before the described patent was filed is not patentable. Anything that is patentable about message passing must have been new, original, not obvious, and applied for before it was disclosed.