> 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.
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).
However, a frame view would - and supporting some level of reassembly at
the frame level could be useful.
> 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?
> 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.
It *would* work for reassembling IP fragments, as a reassembled IP
datagram has 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.
Or it would need to do its own reassembly.
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*.
(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....)
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.
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.
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.
And if this is being used for a *frame* view, it would have to attach
that information to the frames.
