I would like to ask for assistance with investigating a communication problem we have with Modbus device over TCP. We 
use 6.3.0 SP3 with all the network patches available for that release. 
The code was running correctly until we raised priorities of communication thread to 52 (it was running with default 
priority of 10 before). Now, once every 15 minutes or something, TCP communication stops for a second (like a packet is 
lost) and then, after a second it continues, but hardware times out without data until that.
I have attached an excerpt from Wireshark capture file with the incident (I can provide full file, if necessary).
So, if to look at packet #13, it's a Modbus query with Seq=37, NextSeq=49. The packet #16 is the response for the query,
  it has Seq=34, NextSeq=45 and it contains Ack=49 confirming that the query has been received by the device. The next 
packet from the node to the device (#17) contains Ack=45, confirming that the response has been received by the stack. 
However its Seq=64 and NextSeq=79 instead of expected Seq=49 and Wireshark states in packet analysis that previous 
segment has been lost. Is not that sequence chain break strange? 
Indeed, the application does not receive the data from packet #16 (the response for Modbus query). I have added receive 
timeout and attempted to resend original query hoping that it will force packet retransmission from Modbus device (user 
level resend - this is what packet #17 and all the next packets from node to device with Transaction Id increasing are).
 But as you can see from the logs, it had no effect. The node and the device keep acknowledging they both have received 
the last packets but it looks like they do not understand each other, as if they speak different languages. At last, 
after a second, the node stack retransmits original packet #13 on its own with packet #31 and the device answers it once
 again with packet #35. The node accepts this answer, confirms it with Ack in packet #36 and device starts answering all
 the 14 user-level retries I've sent during that second of delay (#39, #42, #46, #49 and so on). So, even though the 
communication restores after a second, it's already too late for the hardware and node terminates the socket.
Could someone tell me, please, what was wrong with the first communication attempt (packets #13-#16)? Why did not the 
data reach the application? Which side has lost the packet (the node or the device)? Everything looks exactly the same 
both times except for strange sequence chain break I don't know how to explain.
Thank you for the help and sorry for taking your time.