On Thu, Dec 16, 2010 at 9:43 AM, Matthias Leisi <matthias(_at_)leisi(_dot_)net>
wrote:
[...]
All subsequent lookups for IPs in the same /64 would only repeat these
two (cached) queries/answers and not create new cache entries. Traffic
between application and cache would run hot, though.
with actual use of a recursive focus protocol like the ones we're
discussing, a good query library would probably do its own DNS
resolution.
Here are the layers of the systems under discussion. As the protocol
is going to be tricky to get right, we expect a reusable library to do
the querying, just as is seen with SPF.
LIST SERVER <- dns protocol -> LOCAL CACHE <- DNS query library ->
LIST QUERY LIBRARY <- library API -> APPLICATION
With integration of the LC function into the LQL, that traffic won't
have to be as hot, and the LQL might even be able to make preemptive
guesses based on the specifics of additional data provided in
responses by the LS.
For instance in the focus-on-the-nebula example, the server could
provide the record indicating exactly which pixel has the 2 brightness
as an additional datum with its response to the f-04 query. A full
response set might look like
2+++
++++
++++
++++
f-04: additional focus needed: 1 confidence: 0xFD data: 0x00
2+++
++++
++++
++++
f0-05: same thing
(Arrgh! a one-bit request is for 0 or 8, not 0 or 1)
f8-05: no additional data available at higher focus, data 0x00
2+ ++
++ ++
f0-06: same as f-04 or f0-05
f4-06: same as f8-05
2 +
+ +
f0-07 will still be 127.1.253.0
f2-07, f4-07 and f6-07 will all be 127.0.255.0
2
and f0-08 is 127.0.255.2
That's eight records. I don't know exactly how much additional
cacheable data can be provided along with a DNS answer, but providing
the next few interesting data in the area being queried about will
reduce traffic between the LC and the server.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg