Richard Sharpe wrote:
>At the moment, I am focussed on a build-time system, but I now tend to
>agree, after seeing Laurent's posting about binary distributions, like
>the Linux world that I live in, that a run-time interpreter may be needed.
>
>More thought is needed.
Of course, the building one does not preclude building the other. There are
always going to be troublesome protocols with special cases that just
require some work in C to get them decoded properly. So designing a
run-time interpreter that covers all cases might be an unreachable goal.
However, there is still value in covering some of the easier cases with a
run-time system. A simple run-time interpreter that could be configured
fairly easily would be a neat feature and would catch attention. Especially
if there were a way to program it visually by using actual packets as a
guide. I don't know of any commercial product that can be adapted to new
protocols this way.
Another way to approach this would be to look for cases where protocol
definitions already exist in other forms and use them as your input. I've
long thought it would be cool to have a packet capture product that could
read the same input files that rpcgen uses in order to interpret Sun RPC
requests. That way you could just feed it the .X file for your RPC program,
and the packet capture tool would be able to decode requests using the same
nomenclature the program does internally.
To cover the cases not reached by the above, a more full-featured build time
system for automatically generating C code would be of value as well.
Especially if the generated C code could then be tweaked by a knowledgeable
programmer.
Basically, I think both approaches have value, for different reasons.
=====================================
Tim Farley
Software Engineer
tfarley@xxxxxxx
Internet Security Systems, Inc.
(678) 443-6000 / Direct Dial (678) 443-6189 / fax (678) 443-6479
http://www.iss.net
Adaptive Network Security for the Enterprise
=====================================
