Good Way to keep track of UDP congestion

Hi there,

I am currently coding a Server that is going to use UDP and TCP for different tasks and am slightly worried that the lack of congestion control for UDP might result in TCP going overly defensive and basicly stopping transfer. Also if i read correctly, agressive UDP messaging can result in congestive collapse which means the more i try to send the less goes through so i should propably avoid just trying to mindlessly send and hope for the best. All this might be idle musing for i have no idea if i ever get nearly enough visitors for this to become an issue but i just like to broaden my horizon and plan ahead on stuff like that. ;)
So far so simple - now i was looking for ways to get information about my connection for now i found three possible solutions, neighter of which really satisfy me:

1) Using TCP congestion control
If i read correctly, setting up a raw socket on the same adress allows me to tap into ICMP and read the "Source Quench" packets that are emitted if a router wants TCP to slow down.
Advantages:

• Uses no additional overhead, ECN allows proactive reaction

Disadvantages:

• ECN not always supported (might be outdated info)
• I measure remote connection problems too - if i take the average this might
  balance out a bit but still...
• I am actually not sure if i have tcp connections at all times - tcp is mainly used
  for patch distribution so if there was no recent patch but i still want to avoid
  congestive collapse this won't help

2) Using DCCP instead of UDP
Advantages:

• Basically UDP with congestion control and even supports ECN -
  seems perfect for my scenario at first glance

Disadvantages:

• ACK Packages add a little overhead
• Wikipedia article reads as if there is no implementation on Windows at all
• Again we're not measuring local congestion but averaging remote congestion

3)Get a list of reliable IP-Adresses and ICMP Echo (aka Ping) them
Advantages:

• Overhead doesn't increase with number of connections to my Server
• If i pick the right Servers where connection on their side is not an issue, i should have an accurate measure for my own congestion

Disadvantages:

• Manual configuration of IPlist required
• To find Servers right outside the network i have to traceroute from multiple
  starting/ending points and guess where intranet ends and internet starts if i
  get a reply at all
• Those Servers propably have that good a connection because they agressively
  go against DoS-Attacks, so my constant spamming of Ping Requests could quickly result in an IP-Block

I favor the 3rd proposal right now however i still hope i simply overlooked a protocol or something - all that would actually be needed is a way to query a router once every second or even less often for his load status and get something as simple as a percentage of max load back. Since i doubt this problem hasn't already occured to a lot of people i guess there is an answer out there but i just failed to find the proper search words for google or something ^^.

Anyway i would much appreciate to learn how you did /would go about fixing that issue or if you think that one can only properly resolve it if you have access to the router.

There is no guaranteed way by which you can monitor the intermediary routers. One way to keep congestion low is to keep the UDP packet size large enough. You could try sending probe packets every now and then and measure the RTT and control the flow based on that (somewhat like what TCP Vegas does). If you feel that your network might get congested (although, this is unlikely in most scenarios), it might be safer to use TCP instead of UDP.

Not the answer i was hoping for but thank you regardless - i guess i'll mix 1) and 3) to get stable TCP connections and check for congestive collapse.
If i switch ping servers frequently enough i may not be regarded as a threat by the anti-dos-code they got in place.

Most servers have ICMP echo (ping) turned off. It's best not to rely on ping / traceroute as there is no guarantee about their behavior.

Running both tcp and udp is fine, but it sounds like you want a way to have a way to send reliable UDP packets and unreliable as well. It would be much simpler if you could stick with either tcp or udp for your connection.

I suggest checking out enet: enet, or UDP_Engine: Getting Started.

Both of these library offer reliable UDP transmission and even the code so you can take a look at how they are implemented.