Dropping / deferring requests

[ayourtch]

Ray,

I see that dropping/delaying the requests is "todo", and I needed it for one of my experiments, so I wanted to share some experience of how I did it for your info and feedback.

I was able to get it working rather nicely by adding another bit flag called "defer" to the struct evldns_server_request, and another member called "queue" which is a function pointer with the signature like that of the evldns_server_udp_write_queue, and changing the signature of *_tcp_write_queue to match (and return always 0).

Then evldns_tcp_accept_callback or evldns_udp_read_callback can set the req->queue accordingly.

Also I added an early return from server_process_packet with -1 if the req->defer is set - which avoids any writes if the callback sets it.

Thus, the deferred reply code simply needs to set the req->defer and kick off the long activity with user ptr being the struct evldns_server_request pointer.

Upon the completion of that activity, the callback prepares the wire format by
doing ldns_pkt2wire() call that is otherwise done in server_process_packet, and then call the req->queue(req).

With this, I've quite easily implemented a prototype DNS64 A-filtering proxy based on static.c example and evdns clientside async resolver: for A requests, return 0 replies, for AAAA requests, kick off an async AAAA lookup for the target to upstream, upon completion of that either return the answer or if there are no AAAA records, kick off an A lookup - which, when completes can create a synthesized AAAA reply.

Based on this experience, a couple of things that might be worth doing differently/need further work:

1. create a couple of "wrapper queue" functions that would also prepare the on-the-wire format and put them into the req->queue rather than the existing ones

2. there is no way to do either deferred or immediate free of the req... The deferred free can be easily done by exposing the server_request_free(), but since it can not be done from within the callback, probably having another bitflag req->drop which is processed in the respective TCP/UDP routines, might be a viable option ?

--a

[raybellis]

Thanks Andrew, that does seem like a good approach.

Re: your last paragraph, I think I probably need to see that in code to fully grok the issue there. I'm not sure it's even an issue, as the current UDP network functions already call server_req_free() once the response packet is finally transmitted. I may have an issue with handling more than one TCP response, though (oops!)

[ayourtch]

re. freeing - yes, if the UDP packet is transmitted, then the req is freed, I was thinking about the case where rather than handling the response later, one might want to drop it for whatever reason and not send any reply at all - so then free would need to happen outside of the sending code path... Though it is arguably a very corner case for a DNS server, so maybe not worth worrying about. I did not have a need for it, the only plausible use case I can come up with is if one wants to emulate packet loss, for which there are better tools out there, anyway.

[raybellis]

Ah right, I see what you mean, now :)

Perhaps I should add _defer and _discard methods, or similar.

[ayourtch]

Yep, two methods seems nicer! 👍

[raybellis]

I'm going to have to think a bit about how to implement this. The current road block is that persistent TCP connections re-use the same evldns_server_request object and use a hard read-then-write cycle. Supporting proper pipelining when individual requests might be deferred is going to take some major refactoring.

[ayourtch]

If the _defer() were to set the flag, then possibly besides the server_process_packet doing the flag-check in order to bail out early, the calling "if" in evldns_tcp_read_callback could have an "else if" clause that could check the flag - and if it is set, then it would allocate a new req, register the read event on that one, and unregister the read event on the "deferred" req - doing similar work as the accept_callback does... this way the old req will be left dangling.

And an additional check in the enqueue function, which, if the deferred flag is set, would free the req structure similar to udp enqueue already doing unconditionally.

This does litter a bit with the "defer" flag logic in more than one place, but seems relatively pointed changes ?