Click “Read the original text” for more VxWorks resources
In this article, we will explore the principles and structure of the VxWorks network protocol stack. We will provide a detailed analysis and explanation of the VxWorks network protocol stack, the MUX interface, the workflow analysis of the MUX interface, and the applications of MUX.
With the support of various network protocols and products, we have more choices in our work and life. Here we will introduce the VxWorks network protocol stack and related content. VxWorks is a high-performance, scalable embedded real-time operating system launched by Wind River System in the United States. It is widely used in high-tech fields with high real-time requirements such as communications, military, aviation, and aerospace due to its good reliability and outstanding real-time performance, such as satellite communications, military exercises, ballistic guidance, and aircraft navigation. The VxWorks operating system includes several parts: process management, storage management, device management, file system management, network protocols, and system applications. VxWorks occupies very little storage space and can be highly scalable, ensuring that the system can operate efficiently. It can be combined according to user needs, and its open structure supports industrial standards, allowing developers to design effective solutions with minimal work to meet different user requirements.
1 VxWorks Network Protocol Stack and MUX Interface
The network protocol stack in VxWorks is called SENS (Scalable Enhanced Network Stack), which is a scalable enhanced network protocol stack. SENS is developed based on the 4.4BSD TCP/IP protocol stack and includes many protocols that the 4.4BSD TCP/IP protocol stack does not have; moreover, SENS adds many new features when implementing some protocol functions, such as adding multicast functionality in the implementation of the IP protocol. The SENS protocol stack hierarchy is shown in Figure 1.
The basic characteristics of SENS are similar to those of traditional TCP/IP network protocol stacks, but as can be seen from Figure 1, the biggest feature of SENS is the addition of the MUX layer between the data link layer and the network protocol layer. In SENS, the network interface driver is called END (Enhanced Network Driver), which is the enhanced network driver, and it is located at the data link layer. The IP layer and TCP/UDP layer are collectively referred to as the network protocol layer. There is an application programming interface (API) between the data link layer and the network protocol layer, which is called the MUX (Multiplexer) interface in SENS. The MUX interface is shown in Figure 2.
In the network protocol layer, VxWorks typically uses the TCP/IP protocol (and also supports other protocols); in the data link layer, it typically uses Ethernet and supports other physical media for data transmission, such as serial line access methods used for long-distance connections, like PPP, etc. However, regardless of the physical media used, the network interface driver must use MUX to communicate with the network protocol layer (the data link layer is an abstract concept, and the network interface driver is the code that implements the functions described by this abstract concept).
In 4.3BSD, the network interface driver and protocol in VxWorks were closely integrated, communicating with each other by passing specific data structures; however, based on MUX, they only interact indirectly through MUX. For example, when a packet is received, the network interface driver does not connect directly with the protocol layer. Similarly, when the network interface driver is ready to send data to the protocol layer, the driver will call a function provided by MUX. The main purpose of using MUX is to separate the network interface driver from the protocol layer, thus allowing the network interface driver and protocol layer to remain largely independent of each other. This independence allows for loading a new protocol or network interface driver, and all existing MUX-based protocols can use this new network interface driver; similarly, if a new MUX-based protocol is added, existing network interface drivers can also use MUX to communicate with the new protocol.
2 MUX Interface Workflow Analysis
The MUX layer, as an independent network layer, has its own functional functions, but these functional functions are merely the interfaces for communication between the layers above and below it. The calling relationship between the network protocol layer and the network driver with the MUX interface is shown in Figure 3.
The protocols provided by the network protocol stack offer the following interface functional functions:
①stackShutdownRtn()
②stackError()
③stackRcvRtn()
④stackTxRestartRtn()
When the MUX interface layer needs to communicate with the protocol layer, it calls the functional functions mentioned above. To enable the network protocol layer to use MUX, at least the four functional functions above must be implemented.
MUX implements muxBind(), muxUnBind(), muxDevload(), etc. The network protocol layer and network driver interfaces must use MUX access points according to their respective needs. Since MUX is provided by the system, there is no need for additional coding work when using it; just fill in the correct parameters when used.
For example, in VxWorks, muxDevLoad is defined as follows:
END_OBJ*muxDevLoad
(
int unit,
END_OBJ*(*endLoad)(char*,void*),
char* pInitString,
BOOL loaning,
void* pBSP
)
Copy
Other functional functions in the network protocol stack MUX are detailed in the muxLib.h file.
The network interface driver must implement endLoad(), endUnload(), endSend(), and other functional functions. MUX uses these functional functions to communicate with the network driver. When writing or loading a network driver that uses MUX, all the functions in the END shown in Figure 3 must be implemented. These functional functions are specific to each network interface, meaning that each network driver must have these functional functions.
3 Applications of MUX
3.1 How the System Starts and Uses the Network Interface Driver – END
During system startup, a task (similar to the concept of a process, it is the execution unit in an embedded operating system) is executed to perform the following functions:
① Load and start END from memory;
② Register interrupts to handle END;
③ Implement packet handling functions through END.
When the system starts, VxWorks generates a tUsrRoot task to perform the following functions: first, initialize the work queue for network tasks, and then generate a tNetTask to handle tasks in the network task work queue.
The tNetTask task calls muxDevLoad() to load the network interface driver; the endLoad() access point for the network driver device has been defined in tNetTask, and muxDevLoad() will also execute endLoad(). EndLoad() initializes the device and returns a structure named END_OBJ. MUX adds a pointer to the END_OBJ that points to a function that can send data to the upper layer of MUX. Then MUX adds the returned END_OBJ to the linked list of END_OBJ structures. This linked list includes all available network devices in the current system. Once returned from muxDevLoad(), the network device is ready for use.