I’m trying to send messages between a few computers and would like to use name_open to find the connection IDs but names do not appear to propagate across nodes with different endianess.
I have 2 little endian nodes (x86, armle-v7) and one big endian node (ppcbe) all running QNX 6.5.0. They all have qnet and gns running with the x86 node acting as the gns server. Although the nodes can see each other on the network ( i.e. ‘ls /net’ from any node shows all 3 ) in /dev/name/global/net they can only ever see the like-endian nodes.
Is this a limitation of gns? Is there a way around this? Have I done something wrong
Thanks.
I remember when they talked about this when releasing QNX 6.0. That was a long time ago. I thought the main issue was the embedded values in the message, and not something with the headers. That would imply that message passing could occur cross endian, but that standard services, like file I/O would not. I’m now guessing that this was incorrect. I would not count on this in the near future. You could try using TCP/IP or at a higher level, SIMPL.
Thanks. I’d like to avoid using generic TCP/IP messages but it is looking like that may be the solution.
The wiki page that Tim pointed out seems not to be updated that frequently since the “latest” information was posted in 2007, and I am still hopeful that cross-endian support has improved since then.
QNX does claim to have some cross-endian support in their latest documentation, for example in the “Advanced Qnet Topics” for 6.5.0 they state: (qnx.com/developers/docs/6.5. … opics.html):
"
Qnet has limited support for communication between a big-endian and a little-endian machine … If you require cross-endian networking with Qnet, you need to be aware of these limitations:
Not all QNX resource managers support cross-endian. The ones that support cross-endian are: pipe, mqueue, HAM, io-char, devf, ETFS, and parts of proc (name resolve in procnto, /dev/shmem, pathmgr and spawning handle cross-endian messages, but procfs doesn’t.)
"