3 ms·
If you absolutely positively need to have that lowest lag time between points then UDP is the way to go. However 1) UDP will drop the occasional packet. 2) UDP
by BatFastard 13y ago
If you absolutely positively need to have that lowest lag time between points then UDP is the way to go.
However
1) UDP will drop the occasional packet.
2) UDP will NOT work behind many corporate firewalls.
3) UDP connections between users on separate networks will fail due to random configuration issues (I am sure there is a reason, just don't know what it is after years of looking).
4) UDP connections between users on the same DHCP servers requires a different addresses then the global address to make connections.
5) UDP connections can time out if you don't send anything for a few minutes. Easy to fix, hard to find.
In the virtual world platform my team wrote, we started using UDP exclusively, then moved to mixed TCP and UDP, then moved to using TCP for everything except P2P voice connections. with UDP I had always dreaded going into see a potential corporate client, and not knowing if my networking was going to make it through the firewall.
This is a good discussion of the subject. http://stackoverflow.com/questions/992069/ace-vs-boost-vs-poco http://stackoverflow.com/questions/992069/ace-vs-boost-vs-po...
- paraboul 13y agoThere are no such thing as "UDP connections". UDP is datagram based : you send a packet to an address, either it reaches its destination either it not (regardless of the order). A packet can be dropped in case of network congestion, TTL that reaches 0, etc. That is : One can easily rewrite a TCP-like on top of UDP.
- pjc50 13y agoAlmost every real use of UDP is "pseudo connection based", and lots of NAT systems operate on that basis: that a packet going (host,port) -> (host2,port2) implies both that there might be packets in the reverse direction and further packets between that pair of ports. This isn't baked into the protocol, but in practice everyone relies on it.
- jws 13y agoNAT mapppings will time out.
- BatFastard 13y agoWhile a UDP datagram not a "connection" in the TCP sense. You often send a packet via UDP from a port on one machine, to a different port on the same or different machine. If one of those ports changes, then it effectively "breaks" the connection. Since you are no longer getting data on the port you expect to receive it from. So while a pair of UDP ports are not a "connection", it is often a useful abstraction to treat them as one.
- the_mitsuhiko 13y agoA firewall treats continuous messages exchange between two endpoints as a connection. This is also what NAT punching takes advantage of.
- hawleyal 13y agoYou are objecting to semantics, not substance.
- JoeAltmaier 13y agoAll true, if you read 'connection' to mean 'path'. Yes firewalls are an issue. Often HTTP tunneling is tried because 'HTTP will always work' but in practice HTTP has more pitfalls than UDP. There are 100 firewall settings about HTTP; you have to get them all right to stream HTTP thru a firewall (and proxies and ISP servers in the same path). Whereas UDP usually has exactly one setting: enable UDP. We've been poking UDP holes in firewalls for 5 years; its the best (most frequently successful) option for enterprise by far. Failures to communicate on the same subnet with UDP are the wellknown 'hairpin' issue, where some routers will not recognize their own outside IP address and short-circuit a packet back to another subnet inside their domain. Not a lot you can do about it, except use TURN or another UDP proxy.