Hi,
here are some further thoughts on per-frame state information.
I think that a linked list of per-protocol (using the proto index) state
information per frame would be fine. Most frames would have nothing, so
would have a null for the pointer. I would keep head and tail for easy
insertion and keep sorted for quick finding.
I expect lookup to be more frequent than insertion, but would not expect
lookup to occur more than about 1.5 times per packet/frame. Most protocols
do not require state to decode, and some do while sister protocols don't.
For example, it seems that the recently decoded logon protocol does not,
while the LanMan API does.
I think that each protocol module should manage its own memory, just as the
conversations stuff does now, but I think that there will be far more
blocks of memory allocated than there are now. For example, for the LanMan
API, there is likely to be one or two conversations in a trace, with each
conversation having 10 to 100 LanMan API calls and responses. If the trace
is even larger, and I have seen some large ones, then we may run out of
space.
I don't think we can easily reallocate a memory pool, and are faced with an
expensive move operation if we run out of space. Can anyone suggest any
ideas?
I guess we could simpy give up on state, or we could have a list of
allocation areas, but that becomes ugly. We could also pass in a parameter
that allows the user to manually increase the default size of the
allocation area.
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, Master Linux Administrator :-),
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Co-author, SAMS Teach Yourself Samba in 24 Hours
Author: First Australian 5-day, intensive, hands-on Linux SysAdmin course
Author: First Australian 2-day, intensive, hands-on Samba course