<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Sara,<br>
    <br>
    Thanks for the explanation.<br>
    Just my luck: I did try two queries, should have done another one <span
      class="moz-smiley-s3"><span> ;-) </span></span><br>
    Indeed, the third query uses the next server, great!<br>
    <br>
    I understand the problem; configuring a timeout per upstream server
    seems most logical. If I think of something else I'll let you know.<br>
    <br>
    Cheers,<br>
    Robert<br>
    <br>
    <div class="moz-cite-prefix">On 26-01-16 17:16, Sara Dickinson
      wrote:<br>
    </div>
    <blockquote
      cite="mid:EC92FFBE-304E-4A86-ABCE-3AE6A2D14A3D@sinodun.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <br class="">
      <div>
        <blockquote type="cite" class="">
          <div class="">On 26 Jan 2016, at 15:42, Robert Groenenberg
            <<a moz-do-not-send="true"
              href="mailto:robert.groenenberg@broadforward.com" class="">robert.groenenberg@broadforward.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8" class="">
            <div bgcolor="#FFFFFF" text="#000000" class=""> Hi,<br
                class="">
              <br class="">
              I am looking into using getdns for doing ENUM queries from
              an application. Based on the examples I've build a small
              test application which works Ok as a stub resolver doing a
              query to a configured upstream server.<br class="">
              <br class="">
              According to the API doc (<a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://getdnsapi.org/spec.html#8.7">http://getdnsapi.org/spec.html#8.7</a>)
              a <i class="">list</i> of upstream servers can be
              configured. I would expect that when the first server does
              not respond, the next one is queried. However, I found
              that whatever the number of upstream servers configured
              only the first is ever used (verified with
              tcpdump/wireshark), no matter what the response (or lack
              thereof) from that first server is.<br class="">
            </div>
          </div>
        </blockquote>
        <br class="">
      </div>
      <div>Hi Robert, </div>
      <div><br class="">
      </div>
      <div>The timeout associated with the context is the total timeout
        to get an answer for the query. In the current implementation
        when using UDP, the same value is used to wait for a response
        from a particular upstream, so the first query on a context will
        use the first upstream and timeout the API call if no response
        is received within that time. </div>
      <div><br class="">
      </div>
      <div>For a particular context g<span style="color: rgb(51, 51,
          51); widows: 1; background-color: rgb(255, 255, 255);"
          class="">etdns does use the upstreams in order, however if 2
          timeouts are received from a particular upstream then a
          'back-off' is put in place and the next upstream is used until
          the 'back-off' has expired and then the failed upstream is
          tried again. So if you re-try timed out queries on the same
          context you should see this behaviour. </span></div>
      <div><span style="color: rgb(51, 51, 51); widows: 1;
          background-color: rgb(255, 255, 255);" class=""><br class="">
        </span></div>
      <div style="widows: auto;"><span style="color: rgb(51, 51, 51);
          widows: 1; background-color: rgb(255, 255, 255);" class="">(Note:
          TCP/TLS is a little different </span><font class=""
          color="#333333">because if a problem is detected when
          trying to perform the handshake then the next server is tried
          immediately as long as the overall timeout hasn’t expired).</font></div>
      <div><span style="color: rgb(51, 51, 51); widows: 1;
          background-color: rgb(255, 255, 255);" class=""><br class="">
        </span></div>
      <div><span style="widows: 1; background-color: rgb(255, 255,
          255);" class=""><font class="" color="#333333">We have had
            discussions about how to improve this, for example, letting
            the user specify the individual timeout for an upstream to
            respond and the total time they are willing to wait, but
            just haven’t got around to making the change. If you (or
            others) have ideas for the API change/algorithm to support
            this, please let us know.</font></span></div>
      <div><span style="widows: 1; background-color: rgb(255, 255,
          255);" class=""><font class="" color="#333333"><br class="">
          </font></span></div>
      <div><span style="widows: 1; background-color: rgb(255, 255,
          255);" class=""><font class="" color="#333333">Regards</font></span></div>
      <div><span style="widows: 1; background-color: rgb(255, 255,
          255);" class=""><font class="" color="#333333"><br class="">
          </font></span></div>
      <div><span style="widows: 1; background-color: rgb(255, 255,
          255);" class=""><font class="" color="#333333">Sara. </font></span></div>
      <br class="">
    </blockquote>
    <br>
  </body>
</html>