2

The VxWorks Network Stack



2.1    Introduction

This chapter provides an overview of the components that comprise the VxWorks network stack. Also included in this chapter is a description of scheduling issues associated with the priority of tNetTask.

VxWorks includes drivers that support network connections over serial lines (using SLIP or CSLIP) or Ethernet networks (IEEE 802.3). It also supports connections over a backplane bus using shared memory. The VxWorks network stack uses the Internet protocols, based on the 4.4 BSD TCP/IP release, for all network communications.

In addition to the remote access provided by Tornado, VxWorks supports remote command execution, remote login, and remote source-level debugging. VxWorks also supports standard BSD socket calls, remote procedure calls, SNMP, remote file access, boot parameter access from a host, and proxy ARP networks.



2.2    Supported Protocols and Utilities

The VxWorks network stack includes support for the following protocols and utilities:

  • SLIP and CSLIP
  • IP, Internet Protocol
  • TCP and UDP
  • DHCP
  • BOOTP
  • DNS
  • IGMP
  • ARP and Proxy ARP
  • RIP
  • Sockets (TCP, UDP, multicasting, routing, and Zbuf)
  • RPC
  • RSH, rlogin and telnet
  • FTP and TFTP
  • NFS
MUX Interface

VxWorks supports a network driver interface called the MUX. This interface provides support for features such as multicasting, polled-mode Ethernet, and zero-copy transmission. This interface also decouples the network driver and network protocol layers. This decoupling lets you add new network drivers without the need to alter the network protocol. Likewise, the decoupling lets you add a new network protocol without the need to modify the existing MUX-based network interface drivers.

Earlier versions of the network stack used drivers based on the BSD 4.3 or 4.4 model. Drivers of the BSD model are no longer supported and should be upgraded to the MUX interface model. More information about the process of adding new drivers and protocols to the network stack can be found in the 10. Integrating a New Network Interface Driver and 11. Integrating a New Network Service.

Sockets

This network stack implementation includes two sets of socket calls: one set is source-compatible with BSD 4.4 UNIX, the other set is the zbuf socket interface. This second set of socket calls is useful when you need to streamline throughput.1 Both interface styles provide a highly abstracted communication mechanism that hides environmental details. Data written to one socket of a connected pair is read transparently from the other socket.

Because of this transparency, the two tasks do not necessarily know whether they are communicating with an agent on the same host or on another host, or with an agent running under some other host operating system. Similarly, communicating agents using the zbuf socket interface are not aware of whether their communications partners are using standard sockets or are also using the zbuf interface.

For information on using sockets, see 7Sockets under VxWorks, p.123, and the reference entries for sockLib and zbufSockLib. For information on adding a socket back end to a new protocol implementation, see 11. Integrating a New Network Service.

Remote Procedure Calls (RPC)

Remote Procedure Call (RPC) is a protocol that allows a process on one machine to call a procedure that is executed by another process on another machine. Thus with RPC, a VxWorks task or host machine process can invoke routines that are executed on other VxWorks or host machines, in any combination. For more information, see the RPC documentation (publicly and commercially available) and the reference entry for rpcLib.

Remote File Access: NFS, RSH, FTP, and TFTP

VxWorks implements the remote file access protocols NFS, RSH, FTP, and TFTP. Using these protocols, a VxWorks target can access the files on a remote network-connected machine as easily as if the files were local to the VxWorks system. Conversely, the VxWorks implementation of all of these protocols (except RSH) lets remote machines access files on a VxWorks target just as transparently - programs running on the host need not know that the files they use are maintained on the VxWorks system.

See the reference entries for nfsLib, nfsdLib, remLib, ftpLib, ftpdLib, tftpLib, and tftpdLib, and the following sections: 8.2 RSH, FTP, and netDrv, p.160, 8.3 NFS and nfsDrv, p.165, and 8.4 TFTP, p.171.

Boot Parameter Access from Host

BOOTP is a basic bootstrap protocol. Using BOOTP, a booting target can get its boot parameters from a network-connected host instead of getting the information from local non-volatile RAM or ROM. Included in the information supplied using BOOTP can be items such as the IP address for the target and the name/location of the target's run-time image. BOOTP cannot supply the image itself. Typically, this file transfer is left to a protocol such as TFTP.

If BOOTP is inadequate to your needs, you can use DHCP instead. DHCP, an extension of BOOTP, is designed to supply clients with all of the Internet configuration parameters defined in the Host Requirements documents (RFCs 1122 and 1123) without manual intervention. Like BOOTP, DHCP allows the permanent allocation of configuration parameters to specific clients. However, DHCP also supports the assignment of a network address for a finite lease period. This feature allows serial reassignment of network addresses. The DHCP implementation provided with VxWorks conforms to the Internet standard RFC 2131.

Proxy ARP Networks

Proxy ARP provides transparent network access by using Address Resolution Protocol (ARP) to make distinct networks appear as one logical network. The proxy ARP scheme implemented in VxWorks provides an alternative to the use of explicit subnets for access to the shared memory network.

With proxy ARP, nodes on different physical subnets are assigned addresses with the same subnet number. Because they appear to reside on the same logical network, and because they can communicate directly, they use ARP to resolve each other's hardware address. The gateway node that responds to ARP requests is called the proxy server.



2.3    Setting Task Priorities Relative to the Networking Task

The tNetTask task provides packet-processing services outside the ISR. Processing network packets outside the ISR minimizes the amount of time spent with interrupts disabled. By default, tNetTask runs at a priority of 50. If you launch a task that depends on network services, make sure your new task runs at a lower priority than that of tNetTask. When assigning a priority to a task dependent upon network services, keep in mind the following:

  • an ISR interrupts even a priority 0 task
  • when tNetTask is the highest priority task ready to run, it runs
  • if a user task (typically priority 100) is ready, it runs instead of tNetTask
  • while tNetTask does not run, packets are not processed, although ISRs continue to receive the packets (by default, up to 85 before dropping packets)
Priority Inversion

After a task takes a semaphore with priority inversion protection, its task priority is elevated if another higher priority task tries to take the semaphore. The new task priority is equal to that of the highest priority task waiting for the semaphore. This priority elevation is temporary. The priority of the elevated task drops back down to its normal level after it releases the semaphore with priority inversion protection.

If a task dependent on tNetTask takes a semaphore with priority inversion protection, and if a higher priority task subsequently tries to take the same semaphore, the tNetTask-dependent task inherits the higher task priority. Thus, it is possible for a network-dependent task to elevate in priority beyond that of tNetTask. This locks tNetTask out until after the tNetTask-dependent task gives back the problematic semaphore or semaphores.


*      
NOTE: For more information on priority inversion protection and semaphores, see the reference entry for semMLib.


1:  The TCP subset of the zbuf interface is sometimes called "zero-copy TCP."