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 =====================================
Powered by MHonArc 2.6.10