VxWorks is a powerful and complex operating system, encompassing process management, memory management, device management, file system management, network protocols, and system applications. Currently, VxWorks is widely used, appearing in everything from digital cameras and routers to B-2 stealth bombers and Mars Pathfinders. In the 863 Major Transportation Project's research on the localization of control systems, the DCC (Digital Control Computer) and MCU (Microcontroller Unit) also utilize the VxWorks operating system. During field testing, we discovered that data transmitted based on the TCP/IP network protocol sometimes exhibits packet merging (i.e., several packets sent by the sender are merged into one packet upon arrival at the receiver). To address this issue, we conducted a special study and experiment. This paper focuses on analyzing the packet merging problem in the TCP/IP protocol and proposes countermeasures and methods to solve this problem based on experimental results. 1. Phenomenon and Analysis of Packet Merging Problem 1.1 Phenomenon of Packet Merging Problem TCP/IP packet merging refers to several data packets sent by the sender being merged into one packet upon arrival at the receiver, i.e., the header of the next packet immediately follows the tail of the previous packet. Since the message length and the receive buffer length may not be integer multiples, there are incomplete packets in the concatenated messages. The VxWorks operating system will first put the data transmitted from the network into the system receive buffer so that the user process can retrieve the data from it. Here, it is assumed that the length of the receiver buffer is L bytes. L should have a certain length to ensure that at least one packet of data can be stored. Since the DCC and MCU need to transmit different types of messages for data interaction, the user should set different receive buffers for different messages in the program to store different message data. Here, it is assumed that there are only two types of messages: acknowledgment messages and status messages, which are stored in user buffers of 1 and 2 bytes respectively; the length should be equal to the length of the corresponding message in the user layer, which is assumed to be m and n respectively. The concatenation situation is shown in Figure 1. 1.2 Analysis of message concatenation problem Message concatenation may be caused by the sender, the receiver, or the switch that transmits data. (1) Message concatenation caused by the sender Message concatenation caused by the sender originates from the TCP protocol itself. Because the TCP protocol uses the Nagle algorithm (see RFC896) to improve transmission efficiency, the sender has to wait until it has collected 1460 bytes of data before sending a data packet, or until the send buffer is full before sending a data packet, which causes message concatenation. (2) Message concatenation caused by the receiver Message concatenation caused by the receiver is often caused by the receiver process not processing data in time. The receiver must first put the received data into the receive data buffer, and then the user process reads the data from the buffer. If the previous data packet has not been taken by the user process when the next data packet arrives, the new data packet will be attached to the previous data packet, and the user must read the data from the system receive buffer according to the pre-set buffer size, which results in multiple data packets being taken at once. (3) Message concatenation caused by the switch Message concatenation caused by the switch is often caused by the various components connected by the switch sending too much data in a period of time, which exceeds the processing capacity of the switch. In this way, the data packets that were originally sent separately by the sender are concatenated together in the internal buffer of the switch. Currently, in the experimental field, components using the VxWorks operating system, such as DCC, require a separate port for program downloading, and another separate port is needed for SecureCRT software for real-time monitoring. Simultaneously, data transmission between DCC, MCU, and the central control system must also occur on the same switch. This could potentially lead to the data volume exceeding the switch's processing capacity for a certain period. 1.3 Impact of Message Attachment on the System If message attachment occurs in the system without appropriate handling, the entire system will malfunction. If messages used for data transmission are attached and cannot be processed normally, the receiver will be unable to perform calculations, real-time data will be unavailable, flags will not be set, and the program will be unable to continue. If messages serving as life signals are attached and cannot be processed normally, the receiver will perceive a fault in the sender; if this occurs continuously, the receiver will assume the sender has crashed and shut down the system to ensure overall system safety. 2 Solutions to Message Attachment Problems 2.1 Sender-Side Solutions For message attachment caused by the sender, the following two methods can be used to resolve the issue. (1) Disable Nagle's algorithm Since VxWorks supports the Windows Sockets 1.1 standard, the level item in the setsockopt function can be set to LPPROTO_TCPl, which will disable the Nagle optimization algorithm. (2) Set Winsock kernel buffer to 0 This method can only be used on systems that support the Windows Sockets 2.0 standard (VxWorks does not support it), and can be used when the sender is an industrial control computer and the receiver is a processor using the VxWorks operating system. Just set the level in the setsockopt item to SOL_SOCKET and set the SO_SNDBUF value to 0. 2.2 Solutions for receivers There are also two ways to solve the message sticking caused by the receiver. (1) Increase the priority of message processing tasks The priority of tasks can be easily set using the VxWorks operating system. Use the taskSpawn function to start the task, where the priority value is the priority of the task (from 0 to 255, the priority decreases sequentially). Use this function to set the priority of the message processing task to be higher than other tasks, but to reduce the possibility of accidents, this value should be less than 100, because the default priority of taskSpawn is 100. (2) Packetize the stuck messages. This method specifies that the content of a certain bit of the message data is the total length of the message data of the frame. The receiver first extracts this content. If the length of the data in the buffer is greater than or equal to the length, the data is extracted from the buffer according to the length of the content. If the length is insufficient, the data is not extracted. The data is extracted when the length reaches the requirement. In this way, even if the message sticking phenomenon occurs, the application will process the stuck data into packets, and there will be no data loss and the message ID cannot be identified. The following is a detailed explanation through a specific example. On the experimental line, the MCU sends a status message to the DCC with a length of 84 bytes (message ID is 91H), an acknowledgment message with a length of 20 bytes (message ID is 81H), and a receive buffer of 90 bytes. If the status message is stuck after the acknowledgment message, the DCC will not be able to receive the complete status message. After this situation occurs three times in a row, DCC will consider that the task MCU has failed and the system will stop, so the result will inevitably be wrong. If the message length is placed in the first position of the message and the message ID is placed in the second position, the above diagnostic error will not occur after packet splitting. The processing process is shown in Figure 2. 2.3 Solutions for Switches There are three solutions for message sticking caused by switches: (1) Use a switch with stronger processing capabilities A switch with stronger processing capabilities and larger buffer space can be used. However, a 16-port switch from a well-known foreign manufacturer has been used in the experimental site recently, and the switch has 1MB of buffer space. Using a higher-end switch will undoubtedly increase the cost. (2) Increase the number of switches The workload of one 16-port switch can be handed over to two 8-port switches, and then the two switches can be connected. This method can significantly reduce the data processing burden of one switch, but it will greatly degrade the reliability and security indicators of the system; moreover, as the experimental equipment increases in the future, the method of continuously connecting new switches may cause the network to form a loop, which will cause the network to be paralyzed. Therefore, it is not recommended to use this method. (3) Modifying the switch configuration can set the switch's data transmission mode to no-wait transmission by modifying relevant parameters. That is, after the switch receives data, it does not put it into the internal buffer, but directly hands it to the receiver. This method can avoid the occurrence of packet merging to a certain extent, but when the packet transmission is very close, there is still a possibility that packet merging will continue to occur. 3 Conclusion Through field experiments on the sender and receiver of the four solutions, we found that the effects were not the same. ① When the Nagle algorithm was turned off, it was found that the Nagle algorithm was still in use. The final conclusion is that this is a bug in Winsock and has been confirmed in Microsoft's bug list, so this method is ineffective. ② Setting the Winsock kernel buffer to 0 solved the packet merging problem, but the transmission speed was significantly reduced. According to the test, only about 5 frames of data can be transmitted per second, which is unacceptable in a hard real-time system like VxWorks. ③ Increasing the priority of packet processing tasks can prevent packet merging, but may produce some easily detectable task scheduling problems. ④ Although the packet splitting method cannot prevent merging, it can completely prevent the impact of packet merging on the system. Practice has proven that using packet processing can guarantee the correctness of data transmission even at high speeds, without any side effects and with negligible impact on processing speed. This method has been used in the experimental field for an extended period and is operating well.