On Feb 13, 2017, at 10:00 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Feb 12, 2017, at 11:40 PM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
>
>> I'll accept whatever strategy there is for taps vs. dissectors. A few points:
>>
>> * TRANSUM can only work if it is able to calculate values based on other dissected values (such as smb2.msg_id), so provided the dissected values are available to the tap on both passes (via a protocol tree or otherwise) that would be OK
>
> If the tap is registered with TL_REQUIRES_PROTO_TREE, the protocol tree will be provided to it on all passes. If it's one of these new "early" taps, the protocol tree will have the results of all dissectors except for post-dissectors.
Alternatively, we could have a set of flags used when post-dissectors are registered, including "this post-dissector needs a protocol tree", and, if there are any active post-dissectors that require a protocol tree, one will be generated.
(Not that getting handed a full protocol tree is necessarily the best way to get a *subset* of fields from the packet, but being able to get some fields without generating the entire protocol tree is a lot more work - it might be work that can yield a significant performance improvement, but it's still something that requires some thought.)
