[bind10-dev] Resolver - address database requirements

[Michal 'vorner' Vaner]

Hello

On Sat, Oct 02, 2010 at 11:18:00AM -0700, Jerry Scharf wrote:
> For recursive servers, the idea of a 'database' could be misconstrued. 
> Since all the data is transient, perhaps a better name might be used.

Yes, maybe cache would be better, because people usually expect database to be
some kind mysql or so.

> The normal way I have seen this is that as a query consisting of a 
> qname, qclass, qtype tuple comes in, it is searched for in the transient 
> store. If it is there and the ttl is still valid, the answer (or 
> negative) plus any additional data is returned in the fast path.
> 
> If the answer is not there, the query is stalled and the search for the 
> answer begins. If a second query comes in for the same tuple, it is 
> attached to the first query as waiting for the answer to come back. When 
> the answer is determined, all the queries waiting for the tuple are then 
> answered. This is kind of the opposite of atomicity.

I meant something else. From the interface side, if you have something like
(simplified, there would be more parameters, some error checking, etc):

Addresses *lookup(Name name);
void add(Name name, Callback callback);

you need to write code like this:

Addresses *addresses(cache.lookup(name));
if(addresses) {
  doSomething(addresses);
} else {
  cache.add(name, doSomething);
}

So I think it is better to have something like:
void lookupOrAdd(Name name, Callback callback);

because the code you write then is:
cache.lookupOrAdd(name, doSomething);

And since add contains lookup of the right place to put it anyway, doing two
lookups at two functions looks less efficient and more complicated anyway.

> For the size cap, in the ideal case it is LRU based rather than record 
> TTL. I don't care what www.google.com's TTL is, I don't want it flushed 
> rather than some random name that has been used once. An interesting 
> question would be whether a single hit from the cache on the tuple would 
> be enough to split the store effectively enough to make flushing easier. 
> In other words, if we only flushed tuples that had never been asked for 
> a more than once, would this produce good results and simplify the flush 
> opeation?

No, I meant, if I would go trough the cache clear the old/unused ones, I might
as well throw out the ones whose TTL is in the past, because I can't use them
anyway.

> I think the point of not doing the flush during the fill operation is 
> not such a big one. You are already out of the fast path. What I do 
> think is true is that you never want to take a single entry out of the 
> cache, you always want to flush enough entries to allow the server to 
> operate for a while before the next flush.

Yes, that is what I thought. But why I wanted to use the background task ‒ you
do not get out of the fast path, because you start when you are 95% full, the
background task runs with lower priority, so it does not slow the answering, but
uses the unused rest of CPU time to clean. Otherwise, you need to either stop
answering completely for a while or the next thread would need to be careful not
to start another cleaning while the first runs.


Not that I would like to argue, I just wanted to make sure we understand each
other. Maybe this approach is more expensive or there's not enough unused CPU
time or something. This is just guessing what might or might not be useful.

Thank you

Have a nice day

-- 
XML is like violence. If it doesn't solve your problem, use more.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101003/d884e3e6/attachment.bin>