Transparent Distributed Processing (native QNX network) module
io-pkt ... -p qnet [option[,option]...]
- The lsm-qnet.so DLL has many options to alter
how Qnet functions (e.g. timeouts, retries, and idle times), but
Qnet is optimized to function with its default settings.
Don't use these options unless you're trying to overcome an issue related
to your environment.
Using these options can have a negative effect if used incorrectly.
- Use commas, not spaces, to separate the options.
- When qnet starts up, the builtin io-pkt
Ethernet (en) resolver broadcasts its own mappings on all
This option specifies the time interval, in ticks
(see the periodic_ticks option),
after which the builtin io-pkt
Ethernet (en) resolver rebroadcasts 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, which represents 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.
|| The combination of bind=en and resolve=dns is
- Instead of using raw (DIX blue-book) ethernet packets, encapsulate
Qnet packets with an IP header using its registered protocol number.
This is useful on larger networks where simple L2 switching isn't
possible, and all packets must be routed.
If you use the bind=ip option, you also need to use the
option. The resolver is
used to map the node name to the IP address; you can't
use the default resolver with the bind=ip option.
- 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.
- If you use this option in combination with do_crc,
only packets that contain a valid CRC are accepted.
This option has an effect only when do_crc is also set to 1.
Setting enforce_crc to one causes packets that are received
without a valid software-level CRC generated by the remote mode (i.e.
it's running do_crc=0) to be discarded, because the packet
content's integrity is unknown, and could be suspect.
The default is zero, which allows received packets without a generated
software-level CRC to be processed.
- Change the hostname of the machine.
- Map any incoming user ID to map_uid and map its group ID to
that of map_uid.
- If the incoming user ID is 0, map it to map_uid and map its
group ID to that of map_uid.
- Specify the number of interfaces.
The default is two, and the maximum is four.
- The number of Tx buffers that Qnet holds in reserve before allocating
more; the default is 500.
If your application sends large messages, you may want to increase this
value for performance.
If your application typically sends small messages (most default system
traffic is small messages), you may want to decrease this value to save
- 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.
- Specify the maximum transmission unit (MTU) of a Qnet packet.
The num argument must be greater than 100, and
all nodes in network must use the same value.
The default is 1500.
- 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 the
- Specifying a nonzero value to this option instructs Qnet not to log
errors or events to
You can use this option to squelch events caused by a noisy network
when you're looking for non-network events in the
By default, Qnet logs events to slogger, which corresponds
to a zero value for no_slog.
- The number of times per seconds that QoS/L4
should wake up to perform periodic housekeeping tasks.
The value must be in the range from 1 to 1000;
the default is 5, resulting in a default 200 ms tick.
|| If you change the value of periodic_ticks, you'll affect the
timing of all other options that rely on the timer tick.
- 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 priority to use for the pulse for the QoS periodic transmission
thread and the QoS transmission thread.
|| We recommend that you not change these values; we supply the
qos_per_pri and qos_tx_pri options
for the rare cases where you need to change the priority of the
- The level of verbosity of the output related to connection
management by the QoS.
The default is 0; the bigger the number, the more verbosity.
This option is used for diagnosis.
- The number of retries the Ethernet resolver will perform during an
attempted node resolution before giving up.
The default is 2.
- The number of periodic ticks before the Ethernet resolver retransmits a
node resolution request.
The default is 1.
- Add to the resolver list for mountpoints that follow.
The following values for resolver are built into the
- en_ionet —
broadcast requests for name resolution 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
- file — The resolver_parameter is
the name of the file to use; the default is
The format of the file is as follows:
# This is a comment line
The host.domain represents a Qnet fully qualified domain name
The addr1 and optional addr2
are the interface addresses for the FQDN.
For bind=en, the format of an address
is xx:xx:xx:xx:xx:xx (the MAC address).
If you specify something else, Qnet attempts to load
The default name resolver is en_ionet. For queries how to
create nr-resolver.so, please contact QNX support.
|| The following combinations aren't supported:
- bind=en and resolve=dns
- bind=ip and resolve=file
- 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.
- Cause Qnet to insert a four-byte vlan tag into the packet.
The tag_number must be greater than zero.
If you use this option, Qnet accepts only packets that have a tag value
that matches the given tag_number.
If the driver being used doesn't support 1518-byte packets, you must
also use the Qnet mtu_en=1496 option.
The lsm-qnet.so shared object is the
manager that implements native Neutrino networking,
Transparent Distributed Processing (TDP).
The QoS software layer implements the node-to-node session protocol and
handles the selection of transmission media.
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.
- You can have at most one instance of Qnet running on a node, even if
you're running more than one instance of io-pkt.
- You can't umount Qnet, but you can create an
io-pkt producer module that supports unmounting.
If 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=
A 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:
- mount=x has resolvers a and b
- mount=y also has resolvers a and b
- mount=z has only resolver c
||Once Qnet has a domain, you can't set Qnet to not use a domain; you
can only change the domain.|
You can start Qnet in two ways: either you start it
at the same time as io-pkt, or afterward with the mount
Start a network driver, Qnet, and TCP/IP
at once, with Qnet using the
default DIX blue book ethernet packet type with no CRC
checking, and 1024 descriptors for maximum performance:
io-pkt -d speedo transmit=1024,receive=1024 -p qnet -p tcpip
Start io-pkt, and then use the mount
command to start the driver and Qnet in sequence,
using the actual file names of the shared libraries:
mount -T io-pkt -o transmit=1024,receive=1024 devn-speedo.so
mount -T io-pkt lsm-qnet.so
These shared libraries (with the .so extension)
are actually located in /lib/dll. The mount
utility automatically looks for them there.
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-pkt -d speedo transmit=1024,receive=1024 -p qnet bind=ip,resolve=dns -p tcpip
for more information.
- The directory where, by default, protocol modules and legacy
io-net drivers add entries.
For more information, the documentation for
- If this file exists, your system is using the default startup files,
and io-pkt is running when your system
starts up, the system automatically loads lsm-qnet.so.
For more information, see the
Controlling How Neutrino Starts
chapter of the Neutrino User's Guide.
- An entry that Qnet places in the /proc filesystem.
If you open this name and read from it, the Qnet resource manager code
responds with the current statistics for Qnet.
Qnet doesn't fully support communication between a big-endian machine and a
However, it does work between machines of different
processor types (e.g. ARMLE, x86) that are of the same endian-ness.
If you require cross-endian networking with Qnet, please contact your
QNX sales representative.
Using Qnet for Transparent Distributed Processing
in the QNX Neutrino User's Guide
Native Networking (Qnet)
in System Architecture
Transparent Distributed Processing Using
in the QNX Neutrino Programmer's Guide
QNX Neutrino Core Networking User's Guide