name_open hangs... (using global name space)

QNX DEVELOPERS Realtime and Embedded
1

I’m changing my project so that its constituent processes (daq and sim) are on separate hosts (rather than just the one).
To maintain comms:
I’ve started gns -s on host 1 and gns -c on host 2

host 1:
In my daq code I changed this:

name_attach(NULL, strToDaqFromSim.c_str(), 0)) == NULL)

to

name_attach(NULL, strToDaqFromSim.c_str(), NAME_FLAG_ATTACH_GLOBAL)) == NULL)

then on host 2:
In my sim code I changed:

name_open(strToDaqFromSim.c_str(), 0)) == -1)

to

name_open(strToDaqFromSim.c_str(), NAME_FLAG_ATTACH_GLOBAL)) == -1)

I start daq on host1 (and pidin gives me this: 700455 1 ./daq 10r RECEIVE 1)
the strToDaqFromSim name appears under /dev/name/global as expected.
then I start sim on host2 (and pidin gives me: 1130536 1 ./sim 10r REPLY 700455@EA61677b)
but sim just hangs (on the name_open line) neither failing or passing, when I slay daq the sim then continues as expected (telling me that it can’t connect)

Any ideas?

further to the above, qnet’s running but I’m testing with both hosts as VMs in VMWare.

2

Did you implement the handling of the messages and pulses as documented by name_attach()

3

I’ve taken an existing pair of working processes and migrated one process to another host, thus AFAICT all handling remains implemented, unless I’ve misunderstood your answer (possible).

4

Is your code handling the message _IO_CONNECT?

5

you are correct! cheers for that :slight_smile:
It’s weird that it worked for local connections before though, do you think name_attach( someName, 0 ) (i.e. local) gets away without needing the _IO_CONNECT response? the code I’m working on is quite old so I’m wondering if it’s a hangover from a way back when.

6

Quite possible, the IO_CONNECT stuff appeard in later release if memory serves me right. It’s also quite possible that when being local stuff don’t go through gns.