> On Oct 10, 2013, at 10:20 PM, ronnie sahlberg <[email protected]> > 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 <[email protected]> wrote: >>> On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> Archives: http://www.wireshark.org/lists/wireshark-dev >>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>>> mailto:[email protected]?subject=unsubscribe >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
