What are the limitations...

Qnet's functionality is limited when applications create a shared-memory region. That only works when the applications run on the same machine.

Server calls such as MsgReply(), MsgError(), MsgWrite(), MsgRead(), and MsgDeliverEvent() behave differently for local and network cases. In the local case, these calls are non blocking, whereas in the network case, these calls block. In the non blocking scenario, a lower priority thread won't run; in the network case, a lower priority thread can run.

The mq isn't working.

The ConnectAttach() function appears to succeed the first time, even if the remote node is nonoperational or is turned off. In this case, it should report a failure, but it doesn't. For efficiency, ConnectAttach() is paired up with MsgSend(), which in turn reports the error. For the first transmission, packets from both ConnectAttach() and MsgSend() are transmitted together.

Qnet isn't appropriate for broadcast or multicast applications. Since you're sending messages on specific channels that target specific applications, you can't send messages to more than one node or manager at the same time.

For cross-endian development:

Qnet has limited support for communication between a big-endian and a little-endian machine; however, it is supported between machines of different processor types (e.g. ARMLE, x86) that are of the same endian. 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.)
- For servers that use only QNX messages, you'll need to set the cross-endian flag RESMGR_FLAG_CROSS_ENDIAN in the resmgr_attr_t structure that you pass to the function resmgr_attach() in order to identify it as a cross-endian capable server. The actual byte-swapping code is done in libc.
  Note: Only the servers need to have the cross-endian flag RESMGR_FLAG_CROSS_ENDIAN set; the clients don't require this flag to be set.
- If a server uses custom messages (i.e. devctls), the server will need to be modified to handle different endian messages. Incoming messages will contain a flag to identify whether it is the "other" endian (the big or the little endian). The server would be responsible for doing the endian swap for proper consumption. The server is also responsible for replying in the correct endian of the client. The servers can access the endian swap code that is in libc.
You'll need to make the fs-flash3 library endian-aware.
There is a requirement for readdir() processing in order for the server to handle requests. You'll need to issue one resmgr_msgreplyv() rather than use MsgWrite() one at a time.