I have 2 nodes in a local subnet that are required to exchange messages.
Each node would have Tx and Rx queue. So both nodes are acting as client and server.
This could be easily done using UDP sockets but I’m looking at using qnet to access the queues directly using name_attach() and name_open().
However, gns is required to advertise the service, and a node can only execute in server or client mode, not both.
I’m starting to wonder if qnet is a viable solution for what I need to achieve, or should I stay with the socket approach.
If you are not able to determine a machine to be a server as far as qnet resolution is concern, because for example you need all the machine to be identical then maybe UDP/TCP is better suited. But then again if you want to use FQN instead of hardcoded IP addresses you need a DNS server
We have solve this issue through configuration file in which we assign a machine to be a gns server. That configuration mecanism also includes configuring machine names, ip addresses etc.
Use resource manager framework and forget about GNS. Let’s say RM_A on node A supports “/dev/rm_a”. Then from node B you can open connection with “/net/node_a/dev/rm_a” and send read/write/devctl… messages wrapping your specific functionality.
It may seem like an impossibility but you can have two way communication. The most obvious solution is for each process to have two threads. One thread acts a client and the other server. It is also possible to have two way communication using a single message path, but it involves polling. This is not as awful as it sounds as it is network polling, not cpu bound polling.