![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Index]](keyword_index.gif) |
![[Next]](next.gif) |
|
|
|
|
As the Internet has grown to become more and more visible in our daily lives, the protocol it's based on -- IP (Internet Protocol) -- has become increasingly important. The IP protocol and tools that go with it are ubiquitous, making IP the de facto choice for many private networks.
IP is used for everything from simple tasks (e.g. remote login) to more complicated tasks (e.g. delivering realtime stock quotes). Most businesses are turning to the World Wide Web, which commonly rides on IP, for communication with their customers, advertising, and other business connectivity. QNX Neutrino is well-suited for a variety of roles in this global network, from embedded devices connected to the Internet, to the routers that are used to implement the Internet itself.
Given these and many other user requirements, we've made our TCP/IP stack (npm-tcpip) relatively light on resources, while using the common BSD API.
We provide three stack configurations:
The QNX TCP/IP suite is also modular. For example, it provides NFS as separate modules. With this kind of modularity, together with small-sized modules, embedded systems developers can more easily and quickly build small TCP/IP-capable systems.
To customize our TCP/IP suite, developers can also obtain a source release of several components (e.g. io-net, npm-tcpip.so). The source kit also includes simple source examples of io-net modules to help developers create or port source code for the io-net architecture.
As a resource manager, the npm-tcpip module benefits from the code savings and standard interface that all native resource managers enjoy. Due to the natural priority inheritance of QNX Neutrino IPC, clients will be dealt with in priority and time order, which leads to a more natural allocation of CPU resources.
The npm-tcpip suite and dependents.
Most of the link-layer support is implemented outside of npm-tcpip. PPP is implemented as separate shared objects. Since our io-net PPP modules (npm-pppmgr.so, npm-pppoe.so) handle the transmission of PPP packets, there's no need for a memory copy of the packet data. This approach allows for high-performance PPPoE connections.
Note that npm-tcpip acts as a protocol shared library to the io-net process, which directs data to the correct driver. Network drivers are shared libraries as well.
Other components of the npm-tcpip suite (such as the NFS, the snmpd daemon, etc.) are implemented outside of npm-tcpip. This leads to better modularity and fault-tolerance.
The BSD Socket API was the obvious choice for QNX Neutrino. The Socket API is the standard API for TCP/IP programming in the UNIX world. In the Windows world, the Winsock API is based on and shares a lot with the BSD Socket API. This makes conversion between the two fairly easy.
All the routines that application programmers would expect are available, including (but not limited to):
accept()
bind()
bindresvport()
connect()
dn_comp()
dn_expand()
endprotoent()
endservent()
gethostbyaddr()
gethostbyname()
getpeername()
getprotobyname()
getprotobynumber()
getprotoent()
getservbyname()
getservent()
getsockname()
getsockopt()
herror()
hstrerror()
htonl()
htons()
h_errlist()
h_errno()
h_nerr()
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
ioctl()
listen()
ntohl()
ntohs()
recv()
recvfrom()
res_init()
res_mkquery()
res_query()
res_querydomain()
res_search()
res_send()
select()
send()
sendto()
setprotoent()
setservent()
setsockopt()
shutdown()
socket()
The common daemons and utilities from the Internet will easily port or just compile in this environment. This makes it easy to leverage what already exists for your applications.
The database routines have been modified to better suit embedded systems.
You can use configuration strings (via the confstr() function) to override the data usually contained in the /etc/resolv.conf file. You can also use the RESCONF environment variable to do this. Either method lets you use a nameserver without /etc/resolv.conf. This affects gethostbyname() and other resolver routines.
The getprotobyname() and getprotobynumber() functions have been modified to contain a small number of builtin protocols, including IP, ICNP, UDP, and TCP. For many applications, this means that the /etc/protocols file doesn't need to exist.
The getservbyname() function has been modified to contain a small number of builtin services, including ftp, telnet, smtp, domain, nntp, netbios-ns, netbios-ssn, sunrpc, and nfsd. For many applications, this means that the /etc/services file doesn't need to exist.
The QNX Neutrino network manager (io-net) lets you load multiple protocol shared objects (e.g. npm-tcpip.so) This means, for example, that you can load several instances of the TCP/IP stack on the same physical interface, making it easy to create multiple virtual networks (VLANs). You can even run multiple, independent instances of the network manager (io-net) itself. As with all QNX Neutrino system components, each io-net naturally benefits from complete memory protection thanks to our microkernel architecture.
The SCTP (Stream Control Transport Protocol) module (lsm-sctp.so) is a dynamically loadable module that adds SCTP protocol processing to your TCP/IP stack. SCTP is a reliable connection-oriented transport protocol with features such as:
The QNX SCTP implementation makes use of the BSD socket-based API routines along with SCTP-specific API extensions, including:
The IP filtering and NAT (Network Address Translation) io-net module (lsm-ipfilter.so) is a dynamically loadable TCP/IP stack module. This module provides high-efficiency firewall services and includes such features as:
The IP filtering and NAT rules can be added or deleted dynamically to a running system. Logging services are also provided with the suite of utilities to monitor and control this module.
NTP (Network Time Protocol) allows you to keep the time of day for the devices in your network synchronized with the Internet standard time servers. The QNX NTP daemon supports both server and client modes.
In server mode, a daemon on the local network synchronizes with the standard time servers. It will then broadcast or multicast what it learned to the clients on the local network, or wait for client requests. The client NTP systems will then be synchronized with the server NTP system. The NTP suite implements NTP v4 while maintaining compatibility with v3, v2, and v1.
We support DHCP (Dynamic Host Configuration Protocol), which is used to obtain TCP/IP configuration parameters. Our DHCP client (dhcp.client) will obtain its configuration parameters from the DHCP server and configure the TCP/IP host for the user. This allows the user to add a host to the network without knowing what parameters (IP address, gateway, etc.) are required for the host. DHCP also allows a system administrator to control how hosts are added to the network. A DHCP server daemon (dhcpd) and relay agent (dhcprelay) are also provided to manage these clients.
For more information, see the dhcp.client, dhcpd, and dhcprelay entries in the Utilities Reference.
Developed from the Zeroconf IETF draft, nfm-autoip.so is an io-net module that automatically configures the IPv4 address of your interface without the need of a server (as per DHCP) by negotiating with its peers on the network. This module can also coexist with DHCP (dhcp.client), allowing your interface to be assigned both a link-local IP address and a DHCP-assigned IP address at the same time.
We support the Point-to-Point Protocol over Ethernet (PPPoE), which is commonly deployed by broadband service providers. Our PPPoE support consists of the npm-pppoe.so shared object as well as the pppoed daemon, which negotiates the PPPoE session. Once the PPPoE session is established, the pppd daemon creates a PPP connection.
When you use PPPoE, you don't need to specify any configuration parameters -- our modules will automatically obtain the appropriate configuration data from your ISP and set everything up for you.
For more information, see the following in the Utilities Reference:
Our autoconnect feature automatically sets up a connection to your ISP whenever a TCP/IP application is started. For example, suppose you want to start a dialup connection to the Internet. When your Web browser is started, it will pause and the /etc/autoconnect script will automatically dial your ISP. The browser will resume when the PPP session is established.
For more information, see the entry for /etc/autoconnect in the Utilities Reference.
The SRI SNMP Suite for QNX Neutrino consists primarily of ports of the EMANATE and EMANATE/Lite technologies developed by SNMP Research International (SRI). EMANATE/Lite is a statically extensible agent; the EMANATE agent can be extended dynamically. Both agents support SNMP V1, V2, and V3, and include development kits for developers to extend the agents.
Our embedded web server uses very little memory and communicates over TCP/IP sockets. The embedded web server supports CGI 1.1, HTTP 1.1, and dynamic HTML (via SSI commands).
Embedded web server.
Many embedded servers force the user to relink the server in order to add pages, which compromises reliability as vendor and user code compete in a shared memory space.
Despite its size, our embedded web server provides enough functionality to support accessing generated (dynamic) HTML via CGI or SSI.
The embedded web server supports the Common Gateway Interface (CGI) 1.1, a readily available means of handling dynamic data. The downside of CGI is that it's resource-heavy because an interpreted language is often involved.
With SSI (Server Side Includes), a type of command language that can be embedded in HTML files, you can add dynamic content to your HTML. For example, the embedded server can:
Note that SSI tags are available to interact with a data server.
You can also handle dynamic HTML by using what we call a data server. The data server allows multiple threads to share data without regard for process boundaries. Since the embedded web server supports SSI, we've extended this support by adding the ability to talk to the data server.
Now you can have a process updating the data server about the state of a hardware device while the embedded web server accesses that state in a decoupled but reliable manner.
 |
You can write a simple I/O manager to provide dynamic data. Note that this method isn't specific to the embedded web server and that the I/O manager can handle only output, not posts. |
|
|
|
|