8

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.

Dano
  • 239
  • 3
  • 10
  • 3
    they are about 20k. but i already found the reason for this: i sendet too much packets in a too short time-range. They have been stored somewhere in the network stack of the device because the device couldn't proceed them fast enough. Now i wait 75ms between every packet and it works like a charm =) – Dano Aug 20 '12 at 10:22
  • 2
    @Dano If you found a solution edit your answer or answer your own question. Pls. –  Oct 29 '13 at 18:49

1 Answers1

12

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.

Prof. Falken
  • 24,226
  • 19
  • 100
  • 173
Seth Noble
  • 3,233
  • 19
  • 31