TCP will provide you with greater network resiliency but will also use more bandwidth (/cost).
UDP will use less bandwidth but you will be more prone to packet loss. This could be accommodated by developing your own resilience routine between the device and your server.
Hope this helps.
As stated in another reply, TCP provides error correction, whereas UDP just sends the data to an address and assumes it will be delivered. As a result, TCP uses more data, but UDP comes with a risk of occasional packet loss. If your application is getting updates regularly and it doesn't matter if you miss a packet every once in a while, then consider UDP. For example, if you're working on a tracking application and getting location updates every 5 minutes from the device, you could miss a packet and still know where the device is within 10 minutes. If the tracking device is for your child, this might be too long. If the tracking device is for your dog, it might be ok.
Also keep in mind that idle session timeouts are generally 60 minutes for TCP and 5 minutes for UDP. This means if you are using UDP and you don't send any data for more than 5 minutes, the data session will end and you may have to wakeup the device to get it to connect again. Note that if you have a VPN connection between your data center and the operator data center, the session timeouts could be much higher (14 hours).
most facts are stated in the other posts already, but always be careful. Wireless enviroments have often strange
sideeffects, even on TCP. In general your application hat to check an data integrity as well, because in my
experience you never can rely fully on TCP via wireless.
This could lead you to use UDP, but on most GPRS networks TCP is higher priorized and handled better than
UDP. I have seen situations on some networks where all small UDP packets were dropped by the carrier.
Here are some numbers as well
UDP packet header: 20 bytes in general
TCP packet header: 40 bytes, but often 52 - the same for the ACK
3 packets for opening a socket and 2 for a close
Many GPRS networks are natted, this means your TCP Sockets have timeouts from 5 to 30 minutes
(after this time with data the Sockets will be closed, sometimes even without informing you correctly),
for UDP there is a similar timeslot in which a UDP-Reply will be passed through the natting device, this timeslot
is usually about 90 seconds.
hope thats helpful :-)
Though operators may block a particular protocol, they do not have the means to prefer one over the other, nor would it be prudent to do so, given that the IP content is unknown.
As for Alex's problem, assuming packet drops were validated from device and server logs, this may have been due to packet sizes exceeding the operator's maximum. For general IP traffic, the maximum packet size is 1500 bytes, but it will be smaller (nominally, ~1400) for operator networks to account for the GTP overhead. If you don't know your operator's max, you can test this with pings of different sizes.
I hope this helps.
its already some years ago, the carrier was eplus in germany and they dropped UDP packets which were smaller than 20 bytes. So we had to add some "waste" payload to get the packets through.
I have no clue why this packets were dropped, i assume it was a countermeasure against some peer to peer activities.
That TCP is higher priorized is just my empirical view. If i look in echo times for ICMP, TCP and UDP than UDP has for most carriers the highest values, often twice as high as for TCP.
I am just user on IP basis and i have no insight in the GSM/GPRS stuff, so i cannot give any technical explanation, its just my personal observation.
My company run UDP for it's own M2M products, and TCP for some customers.
We really prefer UDP, but it requires a high level protocol if you need to garantee a telemetry. It also depends on payload size.
Why/When UDP ? : We don't have to wait for a TCP negociation or network reply. It's stateless and asynchronous. If you transfer less than 100 bytes, you may send your payload to one server, and immediately duplicate to another one. You send a packet number in your data.
If your server does see a jump in packet number, it means a previous transaction is missing. The server immediately says, over UDP, that a packet is missing with it's number. The device sends again the missing packet(s). Even if you duplicate UDP transactions, it will be less expensive than TCP.
We get a very good control on SIM price (our applications are with 100KB up to 2MB SIMs).
Our application is on moving assets. We can't garantee everytime we wake up that we have 6s of good GPRS network. With TCP, you may initiate your transaction, but not finish it. Your GSM operator will bill you all the IP packets. Thus you'll have to pay all missed TCP transactions !
With UDP, the transaction is atomic : if the packet has gone to the operator gateway, then you get it. - With UDP you pay only for what you get. -
Our customers really require us to be deterministic about network cost. (< 3 USD per month). When customers are not M2M specialists, then they prefer TCP to rely on a known protocol.
We keep TCP for remote firmware update and remote configuration (HTTP files) only.
Hope this experience helps.
All posted information is UDP and TCP and well explained.
If you would like to feel the differences,just see the packet using packet capture software.
if you see the packet, then you will get the point.
1. Wireshark ( ethereal ) in windows OS
2. Linux dcpdump in linux OS
-- Packet blocking from ISP sides , Blocking is depends on ISP operation.
1) ICMP and some of UDP
2) Some of well known TcP port like 80,8080,23,21...