|This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.|
Lightweight version of native QNX Network manager
io-net ... -p qnet [option[,option]...]
- When qnet starts up, the builtin io-net
Ethernet (en) resolver broadcasts its own mappings on all
interfaces. This option specifies the time-interval in number of ticks, after which the builtin io-net
Ethernet (en) resolver re-broadcasts 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.
- 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.
If you use the bind=ip option, you also need to use the resolve=dns or resolve=file option. The resolver is used to map the nodename 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.
- 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 network manager:
- 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() function.
- file -- The resolver_parameter is
filename for file.
If the filename is omitted, the default is open /etc/qnet_hosts. The format of the file is:
#comment ... This is a comment line host.domain addr1[,addr2] ......
The host.domain represented a QNET FQDN. The addr1 (and optional addr2) are the interface addresses for the FQDN. For bind=en QNET, the format of an address 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 nr-resolver.so. 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 npm-qnet-l4_lite.so.
|You can't umount Qnet and the full TCP/IP. You may, however, create an io-net producer module that supports unmounting.|
|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 list.
For example, the following line:
You may start Qnet in two ways: either you start it at the same time as io-net, or afterwards with the mount utility.
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:
io-net 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 mount utility.
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
- The directory where, by default, drivers and protocol modules add entries. For more information, the documentation for io-net.
- 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 Starts 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.
The combination of bind=en and resolve=dns is invalid.
Using Qnet for Transparent Distributed Processing in the Neutrino User's Guide
Native Networking (Qnet) in System Architecture
Transparent Distributed Processing Using Qnet in the Neutrino Programmer's Guide