Thread: Good Way to keep track of UDP congestion

  1. #1
    Registered User
    Join Date
    Nov 2010
    Posts
    5

    Post 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.
    Last edited by LokVadnod; 05-26-2011 at 07:09 AM.

  2. #2
    Registered User
    Join Date
    Nov 2004
    Location
    USA
    Posts
    516
    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.
    Code:
    >+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<-.--------.+++.------.--------.[-]>++++++++[<++++>- ]<+.[-]++++++++++.

  3. #3
    Registered User
    Join Date
    Nov 2010
    Posts
    5
    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.

  4. #4
    Registered User
    Join Date
    Nov 2004
    Location
    USA
    Posts
    516
    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.
    Code:
    >+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<-.--------.+++.------.--------.[-]>++++++++[<++++>- ]<+.[-]++++++++++.

  5. #5
    Registered User
    Join Date
    Mar 2010
    Posts
    68

    tcp and udp

    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Am I on the right track
    By romeoz in forum C++ Programming
    Replies: 12
    Last Post: 07-07-2003, 10:10 PM
  2. not on right track
    By Dena in forum C++ Programming
    Replies: 1
    Last Post: 02-23-2002, 07:03 PM
  3. F1 track analyser
    By Unregistered in forum Game Programming
    Replies: 1
    Last Post: 01-22-2002, 09:48 AM
  4. I want to get back on the track..
    By Lameth in forum C++ Programming
    Replies: 1
    Last Post: 11-15-2001, 05:30 AM

Tags for this Thread