Lightweight version of native QNX Network manager
io-net ... -p qnet [option[,option]...]
||QoS software layer implements the node-to-node session protocol and handles
L4 is a software layer beneath the QoS that implements an ISO level-4
style transport to provide guaranteed, non duplicate delivery of data using
the driver layer below it.
Use commas (,) to separate the options (not spaces).
- The number of ticks after which you want the builtin io-net
Ethernet (en) resolver to broadcast its own mappings on all
of its interfaces. This has the effect of automatically populating
the /net directory with all of the connected nodes.
The default is 150 ticks that represent 30 seconds. The value 0 is special because it
not only stops the broadcasted transmissions, but it causes
unsolicited received broadcasts to be discarded. This has the
effect of populating the /net directory only with nodes that
applications on the local node specifically open.
- Specify the interface (e.g. bind=en0) to use.
All /dev/io-net/enX interfaces are used by default.
When you specify more than one bind option, Qnet uses all
the specified interfaces. This is the fastest packet transport.
- Encapsulate its packet with an IP header using its registered
protocol number. With this option, Qnet doesn't use
raw (DIX blue-book)
ethernet packets. This is useful on larger networks
where simple L2 switching isn't possible and all packets
must be routed.
- The number of times QoS should retry to establish a connection
before giving up. The default is 1.
- The number of periodic_ticks before QoS should retransmit
a connection-establishment request. The default is 1.
- The number of periodic ticks until QoS should conclude that
a connection is idle without any traffic and should be
polled with a heartbeat. The default is 50 ticks (10 seconds).
- The number of unanswered connection heartbeats
before QoS concludes that a connection is down. The default is 6.
- Enable (1) or disable (0) software-level
CRC checking of packets by L4. The default is 0.
When you disable CRC checking, it yields the best performance
on reliable hardware.
- Change the hostname of the machine.
- Map any incoming user ID to map_uid and map its group ID to
the group ID of map_uid.
- If the incoming user ID is 0, map it to map_uid and map its
group ID to the group ID of map_uid.
- Specify a network directory. The default directory is /net.
The default domain is either the hostname domain, if
it has one, or the directory with the slashes changed
to dots and reversed. For example, /net/outside/canada
has a domain of canada.outside.net.
The first mount is the default directory and domain
that the local hostname resolves through.
- Whether or not to generate and expect ACK packets.
These packets are
required to guarantee data delivery over networks that may
lose packets, e.g. Ethernet. The value of X can be:
- Generate and expect ACK packets (the default).
- Don't generate or expect ACK packets. Specify this value only when
it isn't possible for a packet to be lost.
Configure all hosts on the network to use the same value for this option.
- The number of periodic_ticks after which QoS
should probe a connection on an interface for which there is no mapping
for the remote node with a broadcasted packet. The default
is the same as the value of conn_up_idle.
- The number of times per seconds that QoS/L4
should wake up to perform periodic housekeeping tasks.
The default is 5, resulting in a default 200ms tick.
|| The two options mentioned above are very important. If you choose the
default value of periodic_ticks (which is 5), you affect the
timing of all other options which rely on timer tick.
- This option is used for diagnosis. The level of verbosity for the output related to connection
management by QoS. The default is 0.
- Add to the resolver list for mountpoints that follow.
The following values for resolver are built into the
- ndp -- Node Discovery Protocol for
broadcasting name resolution requests on the LAN (similar to
the TCP/IP ARP protocol). This is the default.
- dns -- Take the node name, add a
dot (.) followed by the node domain, and send the
result to the TCP/IP gethostbyname()
- file -- The resolver_parameter is
filename for file.
If the filename is omitted, the default is open
The format of the file is:
#comment ... This is a comment line
The host.domain represented a QNET FQDN. The addr1 (and
are the interface addresses for the FQDN. For bind=en QNET, the format of
is xx:xx:xx:xx:xx:xx (the MAC address); for bind=ip QNET, the format
of an address is a.b.c.d in IP dotted notation.
If you specify something else, Qnet attempts to load
The default name resolver is ndp. For queries how to
create nr-resolver.so, please contact QNX support.
- How L4 should handle the received (rxd) packets:
- 0 -- hold onto multiple rxd packets during reassembly (the
default). This results in the best performance.
- 1 -- make a copy of the data in the packets and immediately
return the packet buffers to the driver. This is useful when there's a
limited number of packet buffers provided by the driver.
- The number of ticks after which to forget about
the slow transmit mode (i.e. tightly windowed) for a node.
The default is 1200, giving 240 seconds or four minutes.
The value 0 is special -- it disables slow mode entirely.
- The number of times Qnet should retry a
transmission before giving up. The default is 25.
- The number of periodic_ticks before L4 retransmits
a transmission request. The default is 1.
The npm-qnet-l4_lite.so is the lightweight version
of the QNX manager that implements native Neutrino networking.
It provides faster speed and enhanced
reliability in performance when compared with its previous version
npm-qnet-compat.so. The npm-qnet-l4_lite.so version of the Qnet
stack isn't compatible
with the earlier version with regard to packet and protocol format. By
default, npm-qnet.so is a symbolic link to
||When you specify two or more resolve= options
in a series, the resolvers form a list of lookups for the
directory specified in the subsequent mount=
You may notice that the list of resolvers is terminated by a
mount= option. Any resolve= options
placed after a mount= option form a
new list -- they don't add to the previous
For example, the following line:
- has resolvers a and b
- also has resolvers a and b
- has only resolver c.
You may start Qnet in two ways: either you start it
at the same time as io-net, or afterwards with the mount
The following example shows how you start everything at once with the
default DIX blue book ethernet packet type with no CRC
checking, and 1024 descriptors for maximum performance:
io-net -d speedo transmit=1024,receive=1024 -p qnet -p tcpip
The following example shows how you use the mount
command to start them in sequence,
using the actual file names of the shared libraries:
mount -T io-net -o transmit=1024,receive=1024 devn-speedo.so
mount -T io-net npm-qnet.so
mount -T io-net npm-tcpip.so
The shared libraries mentioned above with .so extension
are actually located in /lib/dll. The mount
utility automatically looks there for these utilities.
If you wish, you can give the full pathname to the
The following example shows how you start everything at once using
IP packet encapsulation instead of DIX blue book:
io-net -d speedo transmit=1024,receive=1024 -p qnet bind=ip,resolve=dns -p tcpip
See mount and
io-net for more information.
- If this file exists, your system is using the default startup files,
and io-net is running when your system
starts up, the system automatically loads
the Qnet module that
/lib/dll/npm-qnet.so points to (npm-qnet-l4_lite.so
by default). For more information, see the
Controlling How Neutrino
chapter of the Neutrino User's Guide.
Qnet doesn't support networking
processors of different endianness. If you need cross-endian
file access, consider using NFS.
If you use bind=en, you want to use
resolve=dns as well.
Don't use the options bind=en and
together; that combination is invalid.
"Network drivers (devn-*)"
"Network protocol modules (npm-*)"
in the Utilities Summary
Using Qnet for Transparent
in the Neutrino User's Guide
Native Networking (Qnet)
in System Architecture
Transparent Distributed Processing Using
in the Neutrino Programmer's Guide