|
|
| (6 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| {{Hierarchy header}}
| | Content moved to M204int page of same name, but history preserved here. |
| The following features are new or changed in [[Janus TCP/IP Base]].
| |
| | |
| ==DNS Retries==
| |
| Prior to Sirmods Version 7.8,
| |
| the [[JANUS NAMESERVER]] command had no facility to call for a retry of
| |
| a DNS UDP packet for which no response is received.
| |
| This meant that if Janus 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 RETRIES parameter for the JANUS NAMESERVER command.
| |
| Setting RETRIES to a positive integer value, say 2, instructs Janus
| |
| to retry as many as two times if no response was received to a DNS lookup.
| |
| Setting RETRIES to 0, its default, means no retries are attempted.
| |
| | |
| On a swamped network, it is probably better to
| |
| set a JANUS NAMESERVER TIMEOUT value of, say, 3 and a RETRIES setting of 2, rather than to set TIMEOUT to
| |
| 10 with RETRIES 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 RETRIES
| |
| 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.
| |
| | |
| {{Hierarchy footer}}
| |