[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Wisdom of server failure errors
From:       David C. Plummer <DCP () QUABBIN ! SCRC ! Symbolics ! COM>
Date:       1988-02-09 9:43:00
[Download RAW message or body]

Here's the algorithm I'm implementing, (which is simplified to get the
main points across).  I also have a list of servers.  I sort it based on
when I got answers and when I got failures, so the order list can
change.  When I ask a question, I (possibly re)sort the list, and scan
down it.  I will continue down the list until I get an authoritative
answer.  Therefore, server failures and no-responses are pretty much the
same:  count that server as failing (for the next sort) and go on to the
next.  Non-authoritative answers go into the database which gets used in
the final event nobody answered authoritatively.

In ideal circumstances, this will latch onto a winning server until that
server loses.  When it loses (for whatever reason), it goes to the end
of the line.  This is better than the Bind resolver (as described by
you), since it doesn't have to timeout from the front of the list.  It
is better than the TOPS-20 server (as described by you) since it treats
server failure as "try later" and does advance to the next possibility.

Note there are a lot of ways a server can lose.  In addition to not
responding and server failure, 
 - it can send malformed packets (as I sent mail about yesterday), 
 - it can send back nothing (e.g., BITSY.MIT.EDU when asked to do a
   recursive query on a TCP connection for a name it is 
   not authoritative for closes the connection), 
 - it can change the opcode (as I described about OCE.ORST.EDU which
   appears to be caused by sun spots)
 - It can reply with the reply/query bit still in the query position
 - It can answer with a different ID.

[prev in list] [next in list] [prev in thread] [next in thread]