> On Oct 10, 2013, at 10:20 PM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
>
> 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?
Possibly, though not all protocols with heuristic tables will have conversations. I'm not sure how easy that would be to determine in a generic way.
> 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.
An extended value string will make that logarithmic at least, or constant if all the values are contiguous.
>> 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
> ___________________________________________________________________________
> 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
