UDP Hole Punching not possible with mobile provider

Question

actually iam coding an android app that receives the pictures of a webcam that it connected to a pc. To gain more fps i use the udp protocol instead of tcp. The idea is, that the pc sends the pictures to the phone's ip and port. But the provider of the phone has different public ports. so i cant address the phone directly. That's why i tried to solve the problem via udp hole punching, but that didnt work. When my phone sends one packet to the pc, the pc gets the phone's public ip and port. that happens every second to keep the conenction open. Then the server sends the webcame frames to this ip and port as fast as he can. but the phone receives just 10-15 pictures wihtin 1-2 seconds. after that the provider seems to filter every following packet or something like that because the phone doesnt receive any further packet.

Now my question is: what is happening (or what is the provider doing) and how can i fix this problem? TCP protocol works but is too slow for streaming because of too much overhead and error corrections.

Answer 1

There are several issues to keep in mind with UDP, which are magnified on mobile networks:

• As you probably know, once you send a UDP datagram, there is absolutely no guarantee that it will get through and no sure way to know what happened if it didn't.

• Payloads larger than roughly 1400 bytes are likely to be broken up into IP fragments. The receiving operating system may reassemble those into a whole packet, but only if every fragment arrives. Some routers drop fragments arbitrarily, some firewalls drop fragments if they contain particular byte patterns, and some limit the rate at which fragments may be sent. Its best to always keep your datagrams small and handle reassembly and repeats of missing pieces yourself.

• There is no flow-control: if any router's buffer is full, everything after that is dropped. Some routers will begin randomly dropping a percentage of packets if their buffers are growing but not yet full. Some firewalls will blacklist a UDP source if it goes faster than some arbitrary threshold.

In general, device and firewall makers tend to treat UDP like crap so as a UDP developer you have to be an extra good citizen to not get dumped on: regulate your flow, remember that dropped packets mean you might be going too fast, and keep the packets small. There is a lot you can get away with in a controlled environment, but if the application will be deployed "in the wild" it will take a lot of careful programming to avoid problems.