[Evan Hughes <ehughes@xxxxxxxxx>]

From: Guy Harris [mailto:guy@xxxxxxxxxx]
> Are you trying to do a stream view, or a packet view, or a frame view?
> 
> A stream view - in the sense of what Follow TCP Stream does, i.e.
> showing a window that shows a textual display of a conversation,
> *without* having a list of individual packets and a protocol tree
> display for each packet - wouldn't show the out-of-order and duplicate
> packet information.
> 
> Neither would a packet view, in the sense of a view showing:
> 
> 	a scrolling packet list window, with one line per higher-level
> 	packet;
> 
> 	a protocol tree pane, showing the protocol tree for the
> 	currently selected higher-level packet (meaning it would start
> 	the dissection at the first protocol layer *above* the
> 	framgentation - UDP for NFS-over-UDP, ONC RPC for NFS-over-TCP,
> 	NetBIOS Session Service for SMB-over-NetBIOS-over-TCP, etc.;
> 	lower-level stuff, such as the link layer or IP, wouldn't show
> 	up in that protocol tree).

   Ummm, I think this is what I mean. After the fragments have been
reassembled, their payload is treated as a stream (ignoring the individual
packets that carried them). "High level" packets are detected in this
stream, and they are displayed. 

> However, a frame view would - and supporting some level of 
> reassembly at
> the frame level could be useful.

  Is this the current view that ethereal provides?

> 
> >     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. 
> 
> Is that a stream view or a packet view, in the taxonomy above?

    It's a packet view (ie, showing Gnutella packets) on the stream. The
packets that carried the stream are ignored: we don't care how the stream
got here, just what it carries.

> >   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.
> 
> It wouldn't work on a TCP stream.

  Okay. That was what I was wondering.

...
> Hand dissectors for protocols running atop TCP the TCP payload, *with
> duplicate data excised, and with the dissectors called with 
> the payload
> data in time order*.

   Ummm, wouldn't we want to elide the data together? Provide the
higher-level (ie, stream level) dissectors with something like a single
tvbuff that represents the entire contents of the stream. The dissector
would be responsible for finding the start and end points of the current
packet, chopping it up, and telling ethereal where in the stream the packet
ends. 


> (Note that no matter *WHAT* you do, the dissectors will have 
> to be able
> to cope with *missing* data; even if there was no missing data on the
> wire, it might not have been captured....)

   In a high level (over TCP) protocol, why would we deal with missing data?
The OS would not inform the application about the missing data until it had
been recovered. 


> The dissector would dissect what packets it can in that TCP 
> segment.  If
> it finds that the last packet is continued in a subsequent segment, it
> would remember what state information it had maintained, and 
> would, when
> the next segment came in, see whether that completes the 
> packet.  If so,
> it'd then dissect that packet, and continue processing the segment; if
> not, it'd update the state information and continue.

   Would the dissector have to be responsible for maintaining state here?
It'd be really nice if ethereal silently paused the high-level dissector
until enough data came in to fill the dissectors request, at which point the
dissector is allowed to continue. 

   I'm imagining that the same high-level dissector would be passed the same
(composite) tvbuff repeatedly. The dissector would request a few fields per
high-level packet. If the dissector requested more data than the tvbuff
held, it would be paused. When the tvbuff grew past the size of data the
dissector requested, the data request would be fulfilled and control passed
back to the dissector. 

> If this is being used for a stream view, that would be sufficient; the
> protocol tree text would be dumped into the stream window, 
> presumably in
> "expand all levels" form.

   I was thinking of something along the lines of only showing the high
level packets. You wouldn't see anything below (since that can be tracked in
the current ethereal ui). Is this what you mean?

> If this is being used for a *packet* view, however, it would have to
> remember, for each packet in the packet list, enough information so
> that, when you click on that packet, it can find the frames that
> comprise the packet, and the parts of the first and last 
> frame that are
> included in the packet.

   Sound hard. 
 
> And if this is being used for a *frame* view, it would have to attach
> that information to the frames.

   Ditto. 

e