Comment # 18
on bug 8589
from Jeff Morriss
(In reply to comment #17)
> Ooh, that's good to know.
> The problem with my current approach is that if you look at packets out of
> order (skip pages, come back up, etc) the "fid" path string will be wrong,
> because it's a stateful information that changes along with the stream.
> With this I could compute the fid tree only on first pass, adding some info
> like "valid between pinfo->fd->num X and Y", and look that up on further
> passes.
>
> Would it be acceptable to rely on frame data number for this?
Yes, I think that's the way it's usually done. One thing I've found useful for
that kind of thing is the _le functions in epan/emem.h (e.g.,
se_tree_lookup32_le()). I've used that when I needed to find the largest frame
number less-than-or-equal-to the current one.
> Will also probably make things a bit slower, if we want to pay the price for
> displaying accurate data (the naive version would mean iterating through the
> whole filename table on insertion if we want to re-use already allocated
> strings, and iterating through all possible fids looking for a matching
> frame data number on display... I'll try to think it through)
Hmmm, slower is OK but that sounds pretty slow. I would think re-using strings
would be a pretty low priority and that indexing by frame number might make
more sense (or by fid?).
> Last silly question, is there anywhere better than a fixed/resolved ticket
> to discuss this? ;)
Well, one possibility would be the -dev list; another would be an open bug
describing the problem we're talking about (could be this bug or another one).
You are receiving this mail because:
- You are watching all bug changes.