14 Zář
2021
14 Zář
'21
14:00
Thanks for elaborating!
In the end I went with PowerDNS and cqueues instead.
/Erik
() ascii ribbon - against html e-mail
/\ arc.pasp.de - against proprietary attachments
On Tue, 14 Sept 2021 at 12:09, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
On 09/09/2021 13.14, Elipsion wrote:
Thanks so much for the quick response,
Do you have any pointers for non-concurrent multi-issue code? Eg.
examples or other modules that do this?
From what I understand from the documentation there would need to be
multiple consume-passes, that are also behaving like producers.
Or should the produce stage just issue all of the requests and the
consumer parse all of the replies?
Well, the "iterate" built-in module also does something a bit similar
(in one mode); otherwise there's nothing really similar.
A produce phase can only create one query for upstream; then it's sent
and the corresponding reply is consumed. As long as things are not
marked as finished, new produce phase will happen again. Theoretically
sub-requests (child kr_query) could be used, but their behavior is
currently hard-coded for certain QTYPEs, so I wouldn't recommend trying
that.
Even so, I don't think any way will be easy, as you're likely to be
"fighting" with the iterator and maybe other parts. Right now kresd
just isn't designed with _these_ kinds of modifications in mind. To
avoid the clashes, it might be easiest to put a module ordered before
iterate and replace the non-existence in packets by a CNAME to the next
name to try - and let iterator and other modules continue on that.
--Vladimir