Ethereal-dev: [Ethereal-dev] RFC framework for graphical extensions like the recent rate_grap
Hi list,
Inspired by the recent rate_graph patch I started thinking about the
possibilities to build some
infrastructure to easily add extensions like above and similar to ethereal.
It has to be very easy to use so people can add many of these extensions
easily.
(if it is easy to use, they will develop)
I would like to start a discussion on the list on the design of such
infrastructure support in ethereal
so we get something that is sane and workable.
I made up the following desireable requirements for these kind of
extensions:
1, it would be nice if the graphical charts would be updated in
semi-real-time, ie it would continously update
while capturing packets.
2, it should be reasonably efficient and not impact too much on the rest of
ehtereal
3, implementation of a new feature should be selfcontained, i.e. only one
new source file and no changes
in any other files.
4, it should only operate on whatever packets are displayed after applying
the displayfilter.
5, changing the displayfilter should automatically cause an update of the
display.
The best I could come up with would require we first port ethereal to use
GLIB2.0 (only GLIB, GTK not required) since GLIB2.0 supposedly have thread
support on all supported platforms and on most platforms
will support thread priorities.
Is it realistic to change ethereal to require GLIB2.0 instead of the current
1.2 version?
Does anyone out there know if one can use GLIB2.0 together with GTK1.2 which
the rest of ehtereal would use?
Well let me explain the design i came up with and everyone else that is
interested can say why my idea sucks and why it is broken and come up with
better ideas.
Assume a new module to print the packet-size histogram, similar to the excel
graph that can be seen in Joerg K's
recent example in ethereal-dev.
The parts of the infrastructure support we need to build into ethereal is
hidden here, it only focuses on how
a graph client might work (which should be as easy as possible so as many as
possible will develop for it)
(all names will be changed to more meaningful/proper ones)
This new module (.c file) would contain one function with the name
void register_graph_client( "FrameSizeHistogram",
void (*startstop)(boolean startstopflag)
void (*threadmainloop)(void)
void (*resetcounters)(void)
)
This function will be automatically called by ethereal upon starting up,
similar to register.c .
The first parameter would be the name to display for this graph to put in
the Tools menu.
The second parameter is a pointer to a function with an infinite loop where
the low priority update graph
functions are kept.
The third parameter would be a pointer function to call to either start or
stop the graph display.
The third will be a callback to be called everytime reparsing of all the
packets have occured so that the graph client can reset all internal state
variables.
When a user select/activates the Tools/FrameSizeHistogram menu item,
ethereal will automatically call
the callback (*startstop)(TRUE) (to start it)
and also create a new low priority thread and that thread will call the
infinite loop in (*threadmainloop)()
When (*startstop)(TRUE) is called, startstop will
1, create a new window/canvas.
2, init/reset any local state variables.
3, register a callback for the appropriate subsystem.
graph_register_callback(FRAME_CALLBACK, void
(*framehistogram_event)(packet_info *pinfo, void
*subsystemspecificdatastructure))
Whenever a packet has been completely processed by packet-frame.c and just
before it will return we have some additional code there to walk the list of
everyone interested in FRAME_CALLBACK and call each of these callbacks.
Whenever framehistogram_event() is called it will parse pinfo or the other
structure, yet undefined, and update some volatile internal state
variables/counters local to the framehistogram sourcefile.
frmehistogram_event() needs to be very cpu cheap and should only update some
variables that the low prio thread will pick up later.
When "FrameSizeHistogram is selected on teh menu, it will kill the thread,
call (*startstop)(FALSE) which will deregister and do cleanups.
The thread that is created will just loop at very low priority, and when it
finds that a state variable has changed
redraw the entire canvas when nessecary.
This design would need us to add some drop-points at various subsystems
where we can do callbacks to whoever is interested in receiveing a call when
such a packet has been processed.
To start with we may only need to do say frame,ip,udp and tcp.
Please, discussion on this topic. If we do it well and easy to use people
will develop heaps of new
graphical thingies for ethereal.
As an example one could then produce one initial example graphical thingy,
say the frame size histogram graph
which would update in semi-real-time for others to use as an example to base
their own ones on.
