At 17:28 2001-03-28 -0500, Jason Linhart wrote:
> >This seems like a good idea. If Analog had a DNSLOOKUP command similar
> >to the UNCOMPRESS command, it would make it simpler to plug-in
> >third-party rDNS tools. Since Analog's goal is to provide only basic DNS
> >lookups, this would encourage the use of plug-in tools when needed.
>
>This would slow things down dramatically, compared to running the
>separate utility first, having it create a DNS cache file, and then
I don't think you're on the same wavelength as the concept was broadcast
on. The separate utility would STILL be a separate utility, except for the
lookup functionality, which would be a plug-in or library of sorts for
Analog. The wholesale DNS resolution would STILL be run *BEFORE* Analog
actually does analysis (not for each individual log item) - though
inherently by design, it COULD be performed dynamically, but that's not the
idea. Analog would call into the cache lookup function for resolution,
which allows the lookup/resolution function to manipulate cache files,
tables, regexps, or real lookups any way it pleases without interfering
with Analog.
>running Analog. One of the big advantages of the separate DNS cache file
>is that it does not have to be in the same order as the log entries.
I made no such suggestion that it be that way -- in fact, I specified that
the DNS cache file would do well to be two separate files, with one being
sorted by IP (which makes it fast to look up if you don't want it all
loaded into memory at once, which would result in severe paging operations
if you're low on memory, which of course might be the reason some people
are complaining of resolution speeds).
> When
>Analog needs to do the lookup, it has to wait for an answer before
>proceeding, but when DNSTran, or jdresolve, does the lookup it can queue
>them up and then output them in any order. This allows a dramatic time
>savings.
Yup. Even better savings if Analog can retrieve those answers without
sequentially reading through the cache file looking for them - the whole
point of my post was to improve upon that (but then, I'm going on someone
else's comment about how Analog processes the cache file, and perhaps the
description I got was incomplete).
>The best we could hope for, would be for Analog to have a setting that
>told Analog to run the separate utility, wait for it to exit, and then do
>it's own processing.
Uh, yep, I'm sure I described just such a thing.
>Of course that is just a two line shell script, so there isn't that much
>point in supporting that.
Except that Analog could provide the name of the logfile it was operating
on (say, if that info was in its config file). it could also play a role
in determining the resolver library function to be loaded.
>The DNS cache file is a flat sequential file, but it gets loaded into
>memory only once, where it becomes an optimized hash table.
Ah, it wasn't described that way - it sounded very much like a sequential
search through the cache file for each resolution, which would definatley
explain why it would be so tremendously slower.
In any event, having a resolution interface of some sort would permit for
external development of improvements to how the DNS data is resolved (such
as netblocks), since analog would just pass the IP of the host it wanted a
hostname for, and the external function would come back with an answer --
however it arrives at that -- a HUGE table, a series of regexps, or a
netblock list, whatever - it returns the result.
>Keeping file formats simple is a big advantage, but Analog doesn't let
>that constrain what it does internally.
Muy suggestion is to allow Analog to *NOT CARE* about the format of the DNS
cache file, by externalizing it's functionality.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
------------------------------------------------------------------------
This is the analog-help mailing list. To unsubscribe from this
mailing list, go to
http://lists.isite.net/listgate/analog-help/unsubscribe.html
List archives are available at
http://www.mail-archive.com/[email protected]/
and
http://lists.isite.net/listgate/analog-help/archives/
------------------------------------------------------------------------
