The Ruida controller uses UDP for data transfer, not TCP. UDP and TCP are protocols, or a standard for how devices talk to each other.
TCP has a bunch of data checking and retry mechanisms built into it, so when you send data using TCP, it’s guaranteed to arrive, and be in the order in which you sent it. It might get delayed, but as long as you have a connection, the data will arrive. It’s a bit like sending something via FedEx - you get tracking information, and can tell when it got there, and it’s insured.
UDP is more like putting a letter in a mailbox. There’s a really good chance it will get there, but you’re never actually sure unless you get a letter back. If the person on the other end sent an answer, but their letter got lost, you’d never know if your message didn’t arrive, or their response was the thing that got lost.
There’s also the fun part that the mailbox only has a single opening big enough for exactly one letter. If you and someone else both try to put a message in the box at the same time, they collide, and neither one makes it through. With TCP, the protocol itself realizes that this happened, and it retries after a tiny random delay, so two people streaming Netflix will degrade performance a little, but not horribly as long as you’re below about 60% of your overall network capacity. With UDP, if two packets collide, they’re just gone forever.
The way Ruida uses the network connection is really simple - we send a block of data and the controller responds with ‘got it’. If we get that, we send the next block, and the process repeats until the file is done. If anything goes wrong, and the controller doesn’t get the message, or we don’t get the reply, the only option is to just give up and try again. For this reason, a direct cable between the PC and the controller is the most reliable option, and the next best is a single router or switch between you.