Jack Jackson wrote:
At 03:14 PM 1/19/2006, Gerald Combs wrote:
Jack Jackson wrote:
>
> The only thing that is slow is when digits are entered. I can enter
any
> number of non-digit characters and there is no delay. A delay
occurs as
> soon as I type the first digit after the ==. See my previous message
> for a detailed explanation of when I see the delay.
>
> It does NOT happen for me in 0.10.12 (I don't have 0.10.13 installed).
Can you try build 17056 or later from
http://www.ethereal.com/distribution/buildbot-builds/win32/? I just
checked in a change that might help.
Thanks, that fixes the delays when an IP address is entered.
Both 0.10.13 and .14-17056 do DNS lookups for each character typed when
the data after the == does not appear to be an IP address, regardless of
whether or not DNS resolution is enabled. I'm not sure but I suspect it
is correct that name resolution should happen here regardless of the
preferences, since there is no point in entering a DNS name here unless
it can be resolved.
But is there a point in doing a *complete* check for the validity of a
filter expression if it can cause UI annoyances such as that? The full
check can be done at the time the filter is "officially" compiled, so
you'll get an error message box for the unresolvable name.
There are at least a couple of possibilities here:
1) don't check the filter's validity after every change to the filter
field - just do it if N seconds have passed since the last change to the
filter field, for some presumably-low value of N;
2) disable name-to-address resolution when compiling the filter to test
whether it's valid - just "resolve" everything to 127.0.0.1 or something
such as that.
1) still leaves the possibility of a delay, but does support checking
the validity of items being compared against IP addresses. 2) won't get
delayed, but won't fully check the validity of the expression.
There is an issue here for OSes that have NetBIOS over TCP enabled
(probably only Windows) - on my XP machine each unsuccessful name
resolution tries three ways: DNS query, then a WINS query, then several
NetBIOS Name Service broadcasts (the delays come from waiting for a
response to the broadcasts). Turning off NetBIOS over TCP gets rid of
the delays, and I suspect that is the only viable solution.
*If* the machine can be configured as a P node, that should turn off the
broadcasts, but that might have other undesired effects.
This is a more general problem - NBT name lookup causes delays in other
places (e.g., mapping IP addresses to host names), at least if you're
not using ADNS (ADNS doesn't support NBT, just DNS).
It's also part of a broader problem; as noted in other mail in this
thread, people have seen it on UN*Xes as well - it's just that NBT makes
it worse.
We could conceivably use ADNS for name-to-address lookup as well, which
would eliminate NBT lookups for those. It wouldn't fix problems caused
by slow DNS resolution or dead DNS servers.
