On Fri, Oct 11, 2013 at 12:41 AM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:
> Evan Huus skrev 2013-10-11 01:51:
>
> On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>
> It might be simpler and almost as efficient to have
> recently-successful heuristic dissectors bubble nearer to the top of
> the list so they are tried sooner. Port/conversation lookups are
> hash-tables for the most part and likely won't be made noticeably
> faster by caching.
>
> The attached trivial patch more-or-less implements the above idea. It
> isn't easy to bubble dissectors to the very head of the list because
> we don't have a modifiable pointer, but it was surprisingly easy to
> bubble them to *second* in the list, which should still be a
> substantial improvement if there are many expensive heuristics.
>
> I don't have any long heuristic captures that I can easily time, but
> I've run a few short ones and at least it doesn't seem to break
> anything.
>
> Let me know if it helps,
> Evan
>
> In the particular case I'm looking at there is mostly no match in the
> heuristics tables except false positives
> the same is true for many of the uint table lookups too as there is RTP sent
> from a tool simulating many
> users with many IP/port combinations making up a huge portion of the
> packets.
>
> Regards
> Anders
If there are heuristic false positives than there isn't much we can do
besides make the individual heuristics better. If the port lookup
isn't effective because you know the ports don't line up, you can
select the "Try heuristics first" option which should help at least a
little.
> On Thu, Oct 10, 2013 at 4:22 PM, Anders Broman <a.broman@xxxxxxxxxxxx>
> wrote:
>
> Hi,
> If we in the UDP/TCP/(SCTP?) dissectors saved next dissector on the first
> pas in say per packet data we could avoid
> repeated calls to heuristic dissectors and port/conversation lookups making
> the second pas faster.
> Does any one see any pitfalls with this idea?
>
> I can think of two ways of implementing it:
> - A new entry in pinfo "previous protocol" or something like that.
> or
> - make dissector_try_uint(), dissector_try_heuristic(),
> try_conversation_dissector() return the protocol
> or NULL;
>
> The second is perhaps cleaner but requires more changes or we could make new
> functions
> dissector_try_heuristic_ret_proto() etc or something like that.
>
> Comments?
>
> Regards
> Anders
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
