< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] question about DNS time to live (TTL)


Hi,

Here's a quick followup question that may simplify things a bit.  Is it even
possible to have one DnsInterface thread running as a singleton as I
suggest?  If so, can that thread use a single DnsStub for all accesses?
Since it has the ResultSink I'm thinking maybe not.

Can I still use a singleton DnsInterface if each calling thread has it's own
DnsStub?  The problem there is that TestDns::thread() wants to process the
same stub every time through the loop.

If I need a separate thread for every invocation, is the DNS cache preserved
from one invocation to the next?  Guess I really just need a tip or two
about how best to do DNS lookups from multiple calling threads.

Thanks,
Dave


-----Original Message-----
From: Dave Mason 
Sent: Thursday, January 11, 2007 3:30 PM
To: 'Scott Godin'
Cc: 'resiprocate-devel@xxxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate] question about DNS time to live (TTL)

Thanks Scott.  That confirms my latest thoughts about how the DNS caching
works.  When I first started working with the DNS classes, I saw in
testDns.cxx that the DnsInterface subclass, TestDns, also inherits from
ThreadIf, making it a standalone thread.  I initially removed the ThreadIf
inheritance, since I already have a multithreaded architecture.  I was
thinking that each thread could instantiate its own TestDns object and do
its own lookup.

Now I'm beginning to think that I'll lose the DNS cache each time a worker
thread deletes its TestDns and related objects.  Would it be better to make
TestDns a child of ThreadIf again, so the cache may live?  In that case
could I make it a singleton, since I think I only need one DNS
object/thread?  Each worker thread could call a lookup method on the
singleton DNS thread.

I hate to be a noob, but I looked through DnsInterface and didn't see the
min ttl mechanism you mentioned.  The TTL cache in DnsStub looks protected.

Regards,
Dave

-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, January 11, 2007 2:31 PM
To: Dave Mason; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] question about DNS time to live (TTL)

Yes - ttl defines how long the entry is cached.  DNS servers specify the
ttl, and it is returned with each query response.  The DNS interface has a
mechanism to configure a min ttl - that will override the ttl return from
the dns server.

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Dave Mason
> Sent: Wednesday, January 10, 2007 10:33 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] question about DNS time to live (TTL)
> 
> Hi,
> 
> I just have a quick question about how time to live is implemented in 
> the DNS classes.  If the TTL has not yet expired, and a new lookup 
> request comes in, does the DnsInterface remember the previous IP 
> addresses that it found the last time it queried the DNS server, or 
> does it always send a new request to the server?
> 
> Is that behavior configurable?  Any pointers about general TTL
behavior
> will
> help.
> 
> Regards,
> Dave
> 
> 
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel