Benefits of Qnet

What works best

The Qnet protocol is deployed as a network of trusted machines. It lets these machines share all their resources efficiently with minimum overhead. This is accomplished by allowing a client process to send a message to a remote manager in the same way that it sends a message to a local one.

See the How does it work? section of this chapter. For example, using Qnet, you can use the QNX Neutrino utilities (cp, mv and so on) to manipulate files anywhere on the Qnet Network as if they were on your machine—by communicating with the filesystem manager on the remote nodes. In addition, the Qnet protocol doesn't do any authentication of remote requests. Files are protected by the normal permissions that apply to users and groups (see File ownership and permissions in Working with Files in the User's Guide).

Qnet, through its distributed processing platform, lets you do the following tasks efficiently:

• access your remote filesystem
• scale your application with unprecedented ease
• write applications using a collection of cooperating processes that communicate transparently with each other using QNX Neutrino message passing
• extend your application easily beyond a single processor or symmetric multiprocessor to several single-processor machines and distribute your processes among these processors
• divide your large application into several processes that coordinate their work using messages
• debug your application easily for processes that communicate at a very low level, and that use QNX Neutrino's memory protection feature
• use builtin remote procedure call functionality

Since Qnet extends QNX Neutrino message passing over the network, anything built on top of message passing also works over the network.

What type of application is well-suited for Qnet?

Any application that inherently needs more than one computer, due to its processing or physical layout requirements, could likely benefit from Qnet.

For example, you can apply Qnet networking successfully in many industrial-automation applications (e.g., a fabrication plant, with computers scattered around). From an application standpoint, Qnet provides an efficient form of distributed computing where all computers look like one big computer because Qnet extends the fundamental QNX Neutrino message passing across all the computers.

Another useful application is in the telecom space, where you need to implement large routers that have several processors. From an architectural standpoint, these routers generally have some interface cards and a central processor that runs a set of server processes. Each interface card, in turn, has a processor that runs another set of interface (e.g., client) processes. These client processes communicate via Qnet using QNX Neutrino message passing with the server processes on the central processor, as if they were all running on the same processor. The scalability of Qnet allows more and more interface cards to be plugged into the router, without any code changes required to the application.

Limitations

• Qnet's functionality is limited when applications create a shared-memory region. That works only 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 nonblocking, whereas in the network case, these calls block. In the nonblocking scenario, a lower priority thread won't run; in the network case, a lower priority thread can run.
• POSIX message queues using the mq (-l mq) implementation work only on the same machine.
• 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.