That would be a good additions, but I always tried to do something like :
as soon as the heuristic dissector found a match then it would
explicitely register itself as the dissector for the conversation.
Perhaps we can make something like that automatic?
Similarly to the current discussion some dissectors (hello smb) has
some really huge value_strings for the response value.
Since a search across a linear valuestring is linear it would be nice
if it could also "bubble" frequent entries towards the head if the
array.
On Thu, Oct 10, 2013 at 4:51 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> 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
>
>> 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