From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5187 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Requirements for new dns backend, factoring considerations Date: Sun, 1 Jun 2014 11:08:29 -0400 Message-ID: <20140601150829.GG507@brightrain.aerifal.cx> References: <20140601063103.GA12091@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1401635330 31475 80.91.229.3 (1 Jun 2014 15:08:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 15:08:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5192-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 01 17:08:43 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wr7NK-00072D-2I for gllmg-musl@plane.gmane.org; Sun, 01 Jun 2014 17:08:42 +0200 Original-Received: (qmail 11495 invoked by uid 550); 1 Jun 2014 15:08:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11484 invoked from network); 1 Jun 2014 15:08:41 -0000 Content-Disposition: inline In-Reply-To: <20140601063103.GA12091@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5187 Archived-At: On Sun, Jun 01, 2014 at 02:31:03AM -0400, Rich Felker wrote: > [...] > Anyway, if we do decide that parallel search suffixes are not > important, parallel A/AAAA queries are still needed and outside the > scope of what res_send can do. It would be plausible to make an > interface like res_send, in terms of which res_send could be > implemented, but which has an extra boolean argument for "send both A > and AAAA versions of this query". Or we could just accept the cost of > having two copies of the query packet (an extra 280 bytes is > negligible, I think) and make a trivial res_multisend that does N(=2) > queries in parallel using packets provided by the caller. Based on the responses so far and my own thoughts on the matter, the way I'm leaning is: - Parallelizing (or even supporting) search domains is low-priority, but it's best to have a design that doesn't pessimize them if we do want to add them or (worse yet) require major redesign again. - The complexity of callbacks, complex interface contracts between layers, etc. is not worth it to save a little stack space. - Parallelism of A/AAAA like we have now is essential. So the design I'm leaning towards is a simple res_msend function which takes a list of caller-provided query packets and produces a result for each one, which the caller can then interpret. res_send is then just calling this function with N=1. At first, search domains would not even be implemented. If we want to add them later, we would in principle have the flexibility to choose between sequential queries via multiple calls to res_msend, or one call to res_msend with a much larger N value, but the search would then not terminate when the preferred results were already obtained but results for the fallbacks were still pending. So I think, unless we wanted to expand res_msend to make some of the queries "weak", we'd be stuck with the sequential fallback. I don't see this as a major problem though. As a variant, res_msend could take a list of iovec structures rather than flat buffers, so that part of the query could be shared between queries. This slightly pessimizes short name lookups, I think, but for near-maximum-length names it would drop the data size from 560 down to ~320. Probably not worth the complexity, but I considered it just because sendmsg() accepts iovecs anyway. Still open to further comments, but if nobody has any objections or new thoughts that cause me to rethink things, I'll probably start implementing this in the next 12-24 hours. Rich