[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
INTERNET namespace: who needs it?
Date: Sun, 15 Oct 89 05:32 EDT
From: cjl@AI.MIT.EDU (Chris Lindblad)
1. NETI:ENSURE-DOMAIN-SERVICE-ENTRIES mistakenly tries to update the
INTERNET namespace for uninterned hosts with names like INTERNET|10.2.0.6
If you have an internet namespace, you just get these trash hosts in
your namespace, which is why this bug hadn't been discovered.
If you don't have an internet namespace, the function just blows out.
2. Old world loads that believe in the existence of the INTERNET namespace
do not react in a civilized manner when the namespace server tells them
there isn't an Internet namespace. The just immediately ask the
namespace server about the internet namespace again. Just a couple of
hosts behaving this way can bog down the namespace server with their
continuous requests. We worked around this with a real kludge. In
(flavor:method :server-top-level neti:namespace server) we sleep for
10 seconds every time we get an object-not-found-in-search-list error
for the namespace "INTERNET". This keeps the namespace server from
There's a simple solution for both of these problems. Instead of
deleting the INTERNET namespace completely, just get rid of all the
hosts in it. That's what I did when I built a new world for our
Incidentally, even though we have many large namespaces (though none as large
as the internet namespace is), we don't use changes files because they
invariably screw up. Instead, we just let the namespace servers reload entire
namespaces whenever they boot and get updates. This has solved many of our
namespace inconsistency problems. This probably cant be done if you have an
INTERNET namespace, because of its size.
Hmm, I've never had any problems with the changes file for our
However, I *can* attest to the fact that the INTERNET namespace should
have a changes file if it has all the hosts in it. I discovered that
we didn't when I made the above change, and that was the reason that
it had been taking 2.5 hours for the namespace server to boot.
I have noticed some problems when we switched from the namespace to
the domain servers. The root domain servers generally time out on
requests for information about nonexistent domains. The Symbolics
resolver marks a server as unavailable for fifteen minutes whenever it
does this. Therefore, after some failing lookups, the next few
lookups may fail immediately, without even sending any domain queries,
because all the servers are believed to be down. My solution has been
to use a site resolver. I replaced all the Root Domain Server Address
fields with just the address of our site domain server (it's also our
gateway to the outside networks, so if it's down the Lispm wouldn't be
able to reach a real root server), and set
NETI:*DOMAIN-DEFAULT-RECURSION-REQUEST* to T. I also set
NETI:*DOMAIN-SITE-RESOLVER-ERROR-IMPLIES-STANDALONE* to NIL, so that
the domain system won't be disabled when the site server is down.
Finally, the namespace entry for the site server specifies use of the
TCP DOMAIN protocol, not the UDP DOMAIN-SIMPLE protocol, so that the
Lispm won't time out while it's recursing.
As an alternate solution to the above problem, Symbolics has suggested
patching the function that computes the default service entries for
hosts gotten from the Root Domain Server Address list to use the TCP
protocol rather than the UDP protocol. My solution has been working
for some time, so I haven't bothered trying this one myself.