On 02/08/2012 02:59 AM, Nick Mathewson wrote:
On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle ondrej.mikle@gmail.com wrote:
I think if we want an extra field in the future, we want to put it after the end of the response (that is, after total_len), rather than having it be optionally in every cell.
OK.
That also means AXFR/IXFR would be off limits (I'm OK with that).
Me too.
Without AXFR/IXFR we could limit total_len to 2 octets.
"End" bit would work, but I find it easier to know beforehand how much data to expect - we don't have to worry about realloc and memory fragmentation. Client could deny request if claimed total_length is too high right away (or later if OR keeps pushing more data than claimed).
Hm. If so, maybe total_len only needs to be in the first cell then.
True. Though I'd prefer it in every DNS_RESPONSE cell, I find "firm" cell structure less error-prone (saving 2 octets per cell does not seem so substantial). The total_length in following cells belonging to the same StreamID could be just ignored.
Just to sum up the changes of DNS_RESPONSE, the new structure would be:
total length (2 octets) data (variable)
So no additional overhead for RELAY_BEGIN.
Case of DNSPort queries - example for addons.mozilla.org with empty cache:
Hang on, is each one of these a *round trip*? I don't think so. That is, you don't need to get the answer for the A query before you do the other lookups; the client can launch them all at once.
libunbound tries to parallelize requests as much as possible, sending bunch of requests first, continuing as the responses return.
(Hm, I've just noticed that when asking a forwarder, libunbound serializes it instead. I'll have to ask about this.)
I wonder, do we want to add a "resolve and connect" mode to relay_begin, as discussed elsewhere in this thread?
Only reason I can think of being useful is for getting NSEC/NSEC3 proof that domain does not exist. Does not seem worth the extra complexity, unless someone thinks of better use.
Ondrej