On Thursday, May 5, 2011, 9:06:27 PM, Chris Maynard wrote:
> Fernandez, Rafael <Rafael.Fernandez@...> writes:
>> There are only TCP packets in my capture file.
> That may be true, but as described in the doc/README.developer file in section
> 1.2 Skeleton code,
> A protocol dissector may be called in 2 different ways - with, or
> without a non-null "tree" argument.
(Not directly applicable to the original question, but...)
Hmm. I note from observation while working with capture files that the
current behaviour is slightly more complicated:
1) There is an initial scan through the complete file with tree==NULL
and columns disabled. Presumably to efficiently let all involved
dissectors construct a view of entire conversations without UI
slowdowns.
2) There is a second scan through with tree==NULL with column info
enabled. This is presumably to allow wireshark to give the appearance
of nice responsive building of the packet list without the initial
dissection work slowing down the UI work. (At least for dissectors
that cache the work done and reuse when pinfo.visited is true.)
3) As and when a single packet in the packet list is selected, a third
call with tree!=NULL is made on that single packet to populate the
tree pane.
(I think 2 was a complete scan, though ISTR there may have been
additional scans later on for subsets as the packet list is scrolled.
Not completely confident on that.)
I suspect this is for files only: the distinction between (1) and (2)
making less sense for live captures, and obviously it not being
possible to visit everything before it's been captured!
Another point is that tvbs from lower-level dissectors get thrown away
between 1 and 2, and 2 and 3, (possibly between individual calls
during 1 or 2, but I don't think I saw that) so a nested dissector
never sees the "same data" twice, can't cache subset/composite tvbs
for later use, etc. (which would be a very useful property sometimes -
this area has come up a few times recently in discussions on
composites and _FROM_FILE handling.)
I think knowing these things is pretty useful for the prospective
dissector writer - it certainly gives a better feel for the dynamics
of dissection and may help optimize the places where expensive work is
done - so I think that section of the documentation ought to be
expanded to mention it.
> If the proto_tree argument is null, Wireshark does not need to use
> the protocol tree information from your dissector, and therefore is
> passing the dissector a null "tree" argument so that it doesn't
> need to do work necessary to build the protocol tree.
> In the interest of speed, if "tree" is NULL, avoid building a
> protocol tree and adding stuff to it, or even looking at any packet
> data needed only if you're building the protocol tree, if possible.
> Note, however, that you must fill in column information, create
> conversations, reassemble packets, build any other persistent state
> needed for dissection, and call subdissectors regardless of whether
> "tree" is NULL or not. ...
>> Can you try removing the "if(pinfo->tcp_tree != NULL)" check?
>>
>> if(pinfo->tcp_tree != NULL) {
>> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
>> get_message_tcpmessage_len,
>> dissect_message_tcpmessage);
>> }
> So again, can you try this?
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
John
--
Dead stars still burn
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
