Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap define

From: Paul Offord <Paul.Offord@xxxxxxxxxxxx>
Date: Tue, 14 Feb 2017 09:02:51 +0000
There definitely is a performance impact when you generate the protocol tree in the first pass, probably 33% longer to load.

Anyway, I have a 23-hour plane journey tomorrow so I'll have a crack at rewriting as a TAP.

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: 14 February 2017 08:55
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Tshark: proto_tree not created on first pass with tap defined

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.) ___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

______________________________________________________________________

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________