Depending on the state of your network, you might run across this scenario from time to time. Packets sent by remote T:LAN units are not arriving in the order they were expected in. This article will shed some light on the reasons and ways to deal with this situation.
T:LANs mark each packet sent with a serial number (increments a counter each time a new packet is being sent out).
At the receiving end, the RCC checks the sequence number field of the last packet it received. Based on that, it knows what serial number to expect next.
If another (instead of the expected) packet arrives (meaning: reception is out of order), then a warning message is printed and the packet is added to a small holding buffer. A timer is started at the same time to limit how long the RCC will wait for the expected packet to arrive. Should the expected packet arrive in time, then it, along with any previously received packets are released in their proper sequence to the RCC packet processing and reception continues as before.
If however the expected packet is not received within the allotted time window, then the RCC will abort any attempt to re-sync the packet reception. It will print an error message indicating the loss of the packet(s), then restart the reception process with the next properly received packet in sequence (skipping any missing packet(s)).
It is important to remember that the T:LAN fires out each packet in sequence. And that independent of medium, larger packets simply take longer to transmit than shorter ones. So out-of-order (OOO) packet reception can happen if for example shorter packets are routed differently, or preferentially, in a network compared to larger packets. It could also be the result of packets traveling down diverging paths depending on the current load in a network, possibly causing some to arrive sooner than others.
The RCC offers a few options on how to deal with the OOO warning messages. Go to TOOLS/OPTIONS/NETWORK and check the TERMINAL tab. There you can set the maximum amount of time the RCC will wait for out-of-order packets to arrive and whether or not such warning messages should be suppressed. If you are running into this scenario more often, try to increase the timeout value, and/or check the suppress notifications option.
Next, follow the network path from where you started your RCC copy all the way to the remote T:LAN you tried to communicate with when encountering the OOO issue. Check for clock slips (T1/E1 links), framing errors or other WAN/LAN faults (check the corresponding STATISTICS screens in each T:LAN) that can influence the proper transmission of all the packets en-route.
The cleaner your network runs, the lower the chance of transmission issues that can trigger OOO or packet loss errors in the first place.
Also, check network loads and how they are handled. Sometimes small adjustments and the requirement to send packets from the same source through the same network path can make all the difference.