I once implemented some state engines on a protocol processor
that added states to the frame storage. When searching though large files
that were big, memory accesses to state info produced a lot of paging
and slowed down bulk packet processing as we fetched around for states.
Since ethereal has a limited number of state layers, you may increade data
locality by using a fixed length array of pointers and protocol IDs at the
cost of memory storage. That way as you churn through the data you don't have
to chase a lot of state info locations unless you really care about that kind of
state. The only corner case on this would be when more state engines "like" a
frame and wanna stash stuff in it than you have array slots. But in some cases
the state may not need a complicated data type and the pointer slot could be
used to store a number. It's a bit uglier but maybe more efficient.
I might also suggest storing the state information in a file format with the
capture to avoid having to do states/reassembly on large files needlessly.
One of the neat ideas the snort guys have is the concept of a reassembly
processor. It would be neat to have a filter that reassembled conversation
streams and stored that information in a format that would make stream
access almost instantaneous because it is precomputed.
(I tend to have these massive capture files that stress out memory and take
forever to load.)
hmmmm..... that's useful enough I should go write it if I can find the time.
cheers,
--dr
--
kyx.net - learn kanga-foo from masters: Ron Gula, Ken Williams,
Marty Roesch, rain.forest.puppy, Theo DeRaadt, Fyodor, Max Vision.
core00/CanSecWest -Vancouver April 19-21 http://www.dursec.com
On Fri, 28 Jan 2000, Gilbert Ramirez wrote:
> On Sat, Jan 29, 2000 at 01:33:39AM +1000, Richard Sharpe wrote:
> > Hi,
> >
> > I want to add a void *per_frame_info field to frame_data along with routins
> > to set and retrieve this info so I can support stashing info along with a
> > frame.
> >
> > This will make many things better with protocols where you have to remember
> > state between frames.
> >
> > Since we do the summary pane all in one go, we get to see each frame, and
> > we can stash things in an association, but this screws up when users are
> > randomly selecting frames and going back and forth ...
> >
> > So, the approach I was thinking of is as follows:
> >
> > On any pass over a frame, we check to see if there is frame info stashed
> > there, and if so, use that if we need to remember things about the frame,
> > but if not, look in any association we have set up.
> >
> > However, it seems that multiple layers may want to stash frame info for
> > their own use, so it seems that what I want is a hash and routines like:
> >
> > void set_frame_info(frame_data *fd, gchar *protocol, void *proto_info);
> >
> > and
> >
> > void *get_frame_info(frame_data *fd, gchar *protocol);
> >
> > What say ye, oh assembled multitude?
>
> Or perhaps a linked list of these frame state structs. The number of
> protocols that need to store state is few, and I doubt there would
> be many protocols doing so in a single frame, so the cost of looking
> through a linked list would be negligible.
>
> --gilbert
--
kyx.net
we're from the future - home of kanga-foo!
