[Evan Hughes <ehughes@xxxxxxxxx>]

From: Guy Harris [mailto:guy@xxxxxxxxxx]
...
> If by "exactly" in exactly what needs to be done" you mean 
> that nothing
> *more* is needed, then you're missing a number of things; see the mail
> message to which I referred for the various ways in which the UI code,
> for example, would have to be changed to cope with packets taking more
> than one frame.

    Would we necessarily want to recycle the normal (packet view) GUI with a
stream view? The packet view contains extraneous information: notably
out-of-order and duplicate packets. Keeping these in the stream view could
lead to confusion.

    It might make sense to flesh out the "follow stream" window: instead of
showing just the text of the stream, break it down into packets in the same
style that the main window is displayed. 

> Trust me on this one, I've been working on the innards of Ethereal for
> years, and thinking about these issues for years (heck, 
> wanting a packet
> analyzer that could do that was what got me interested in developing
> packet analyzers in the first place) - *it's more work than you might
> think*.

    That's why I've stopped installing bits and pieces of GTK and I'm
reading this message. =)

...
> Composite tvbuffs were implemented precisely to handle that sort of
> situation, but you're going to need a heck of a lot more than just "an
> index of packets in a stream".

  As I suspected. They don't seem to be used elsewhere...
 
> For one thing, as I mentioned in the mail message to which I refer in
> this mail and referred in the previous mail, Ethereal does 
> *NOT* always
> treat the packets as a sequential stream of packets; its *first* pass
> through the frames is sequential, 

  The first pass would be the perfect opportunity to create a stream data
structure that would chain all of the packets in their logical order --
either by means of a "previous" and "next" field in the packet, or an
external data structure. 

>but once that has been 
> done, the user
> can select frames in whatever random order they choose, so if 
> there's a
> Gnutella packet spread across frames 12 and 13, you'd better 
> be able to
> handle the user clicking on frame 13 *without* having clicked on frame
> 12 before that.

  If a separate window is used for the frame view, this wouldn't be an
issue. If we're looking at Gnutella packets, we're interested in the stream
of data, not how the stream got here.

  Alternately, we could use the information gained in the first pass to scan
back to the preceding packet(s) and dissect from there.
 
> This means you'd have to associate with a frame that's part of a
> multi-frame packet enough state information to allow the dissector to
> find the rest of the frames that comprise the packet *and* to 
> reassemble
> the *parts* of those frames that comprise the packet into a tvbuff to
> allow the packet to be dissected.

  Yes. Since this is already done in the first pass, there is little extra
cost.

> You'd also have to deal with the *other* issues I mention in the mail
> message in question, *and* you'd have to figure out how to make this
> work for Tethereal, which makes only one pass through the 
> capture file,

  I must admit that I've only looked at ethereal. 

...

  On a related topic: Would the standard dissector signature work on a
stream? As I understand it, dissectors are called on packets with a known
size. 

  When dealing with a stream, we don't know the size of the packets. The
dissector needs some way of signaling ethereal to tell it where the current
packet ends, so ethereal can start processing the next packet at the
following byte in the stream. 

  Do the current flavour of dissectors have provisions for this?

e