|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| The following features are new or changed in <var class="product">[[Janus TCP/IP Base]]</var>.
| | Content moved to M204int page of same name, but history preserved here. |
|
| |
| ==DNS Retries==
| |
| Prior to <var class="product">[[Sirius Mods]]</var> Version 7.8,
| |
| the <var>[[JANUS NAMESERVER]]</var> command had no facility to call for a retry of
| |
| a DNS UDP packet for which no response is received.
| |
| This meant that if <var class="product">Janus</var> does a DNS lookup just when the target nameserver
| |
| is down for an instant, or if the UDP packet gets lost on the network (IP
| |
| networks don't have to guarantee delivery of IP packets), the DNS lookup
| |
| could fail.
| |
|
| |
| The version 7.8 "DNS Retries" feature is
| |
| a <var>RETRIES</var> parameter for the <var>JANUS NAMESERVER</var> command.
| |
| Setting <var>RETRIES</var> to a positive integer value, say 2, instructs <var class="product">Janus</var>
| |
| to retry as many as two times if no response was received to a DNS lookup.
| |
| Setting <var>RETRIES</var> to 0, its default, means no retries are attempted.
| |
|
| |
| On a swamped network, it is probably better to
| |
| set a <var>JANUS NAMESERVER TIMEOUT</var> value of, say, 3 and a <var>RETRIES</var> setting of 2, rather than to set <var>TIMEOUT</var> to 10 with <var>RETRIES</var> at 0. This is so because:
| |
| *If a packet gets dropped, there is no benefit to waiting 10 seconds instead of 3.
| |
| *It is very unlikely that it would take a nameserver 3 seconds to respond to a received request (including packet turnaround time).
| |
|
| |
| It probably does not make sense to set <var>RETRIES</var>
| |
| to a value greater than 2: if packets are being dropped so frequently
| |
| that three consecutive DNS requests are dropped, you have problems much more serious than the failed lookups.
| |
|
| |
| | |
| {{Template:Content index: V7.8 Release Notes}}
| |