Phil Pennock writes:
> So, the IP addresses will be held internally after all?
Yes. In fact they are already.
> How long for? When do they expire?
Until the next time sks recon process tries to connect to a partner, at
which point a knew DNS lookup is done for *this* particular partner and
it
On Mon, Mar 23, 2009 at 12:13 AM, Phil Pennock
wrote:
> On 2009-03-22 at 22:40 -0400, Yaron Minsky wrote:
> > 2009/3/22 Phil Pennock
> > > The gotcha here is async DNS support in O'Caml.
> >
> > I'm sure I'm missing something here, but why is asynchronous DNS a
> > requirement? Why not do the DN
On 2009-03-23 at 10:17 +, Kim Minh Kaplan wrote:
> I think I have a much simpler solution for the problem at hand. As I
> just mentionned the first fix is to not do any DNS resolution at client
> accept time. This is trivial and already in my source tree.
>
> Then to mitigate that membership
Phil Pennock writes:
> On 2009-03-22 at 13:45 +, Kim Minh Kaplan wrote:
>
> However, either the membership_reload_interval option needs to be
> completely removed or the reconserver.ml needs to support it -- leaving
> it as a dbserver-only option seems sub-optimal.
I favor of removing it when
On 2009-03-22 at 22:40 -0400, Yaron Minsky wrote:
> 2009/3/22 Phil Pennock
> > The gotcha here is async DNS support in O'Caml.
>
> I'm sure I'm missing something here, but why is asynchronous DNS a
> requirement? Why not do the DNS queries using threads?
You're not missing anything, I was. I w
2009/3/22 Phil Pennock
> The gotcha here is async DNS support in O'Caml.
I'm sure I'm missing something here, but why is asynchronous DNS a
requirement? Why not do the DNS queries using threads?
y
___
Sks-devel mailing list
Sks-devel@nongnu.org
http
On 2009-03-22 at 13:45 +, Kim Minh Kaplan wrote:
> I see what you mean here... Except that periodic DNS lookups are *not*
> The Right Thing. This is one area where I think SKS got it wrong: it
> should call out to the resolver each time it needs to connect to a
> server and let the caching ha
Phil Pennock:
> 8< cut here >8--
> =item -membership_reload_interval
>
> Maximum interval (in hours) at which membership file is reloaded.
> 8< cut here >8--
>
> There are supposed to be
On 2009-03-22 at 12:47 +, Kim Minh Kaplan wrote:
> Phil Pennock:
>
> > Previously, membership was only automatically reloaded in the db server,
> > not the recon server.
>
> Why do you say this? Reading Membership.get and Membership.test, the
> file is reloaded whenever it is modified. thus
Phil Pennock:
> Previously, membership was only automatically reloaded in the db server,
> not the recon server.
Why do you say this? Reading Membership.get and Membership.test, the
file is reloaded whenever it is modified. thus this patch seems wrong.
Kim Minh.
_
Each of the attached compiles, which means more than it does in some
other languages. I'm fairly confident I haven't messed up. But there's
two approaches.
Previously, membership was only automatically reloaded in the db server,
not the recon server.
Patch sks-mshp-timed.patch makes membership
11 matches
Mail list logo
