> > 1. Add a per frame info store so I can do a better job with SMB decodes.
>
> Yes. Other protocols like Socks5 and VNC need better state storage, too.
...and, if/when we do reassembly (IP fragment reassembly, TCP stream
reassembly, etc.), that might involve attaching to each frame that's
part of a bigger packet (a fragmented IP datagram, a NetBIOS-over-TCP
session service packet, an ONC RPC-over-TCP packet, an HTTP request or
reply) enough information to find the rest of that bigger packet.
> On thing to consider about moving to libdencode, however, is that
> if we're not careful, we could end up slower or using more memory.
> Right now, as you know, Ethereal runs through the entire trace file
> to analyze every packet just enough to get the information to put
> in the list of packet (GtkClist). Inside each protocol dissector is
> "short-circuit" code avoiding a lot of processing if there's no need
> to fill out any proto_tree:
As per mail I sent out earlier, a replacement CList widget that supports
"lazy evaluation" - i.e., lets you specify a routine to call to generate
the data for the columns in a row and, for each row, specify an
argument to pass to that routine; I think MFC has a widget that supports
that, and I think I saw some indication on one of the GTK+ lists that
such a capability would be desirable) might let the first pass through
the trace just do the minimum amount of work necessary to attach to the
frame state information necessary to dissect the frame; the callback
routine for that widget might call "dissect_packet()", or a routine that
calls "dissect_packet()".
This could make the initial pass through the trace much faster than it
is now - the Microsoft SMS SDK's section on writing dissectors for
NetMon suggests that NetMon works in the same way, which would explain,
at least in part, why it reads large captures quickly (filtering and
printing aren't so quick; they actually have to dissect the frames).
> 1.0 also needs a "Protocol" tab in the display optoin notebook
> widget.
Or multiple tabs for different protocols; a mechanism by which a
protocol can register a list of configurable options, giving a name to
use in the preferences file, a name to use in the GUI, a data type, and
a pointer to the variable for it, would be useful.