[net-dns-users] AXFR (was: Re: sep() and is_sep())

[Dick Franks]

On 3 June 2014 07:41, Calle Dybedahl <calle at init.se> wrote:

>
>
> The warning does _not_ say that axfr_next() is similarly afflicted. The
> warning is specifically about what axfr_start() returns. Changing what
> axfr_next() returns is a change in the documented public API (as is
> removing it, obviously).
>

Internal method (and it *is* very obviously that) should never have had POD
documentation in the first place.


> Devel::Size gives me about 3200 bytes for a Net::DNS::RR::RRSIG, so I
> think you estimate is low by at least half. Perl was not designed to be
> memory-efficient...
>
> Unfortunately.
My figure came from seeing how much free memory I had and running a
ZoneFile $GENERATE until it fell over and counting the records as they were
DESTROYed in RR.pm   I cannot see why they were counted twice, assuming
that is what happened.
Whatever the actual figure, it is unworkable.


> In Net::LDNS, we have a method that takes a code reference as its argument
> and runs that code once for every RR in the AXFR, with the RR object as its
> only argument. That way the method can keep as much state as it likes, and
> the amount of memory needed is unaffected by the number of records
> received. I find the interface clean and convenient to work with, but then
> I came up with it so I’m obviously biased in its favor.
>
> Are you arguing for a per-RR call-back as an optional argument to axfr()?

That way, you get your iteration done for free, we get the mechanics we
need for TSIG.

   $resolver->axfr(  'example.com', 'IN', sub { my $rr = shift;  ...  }  );

Q:  Does the call-back function return anything?  If so what do we do with
it?
<%2B46%20703%20-%20970%20612>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20140603/714225ee/attachment.htm>