README for FFPF 1.5 beta 0 by Willem de Bruijn, november 19th, 2005. contact us at ffpf-devel_-AT-_lists.sourceforge.net ----- OVERVIEW --------- this distribution contains the basis of what is to become the 1.5 version of FFPF. ----- WHY IS THIS A BETA RELEASE ? --------- this version is marked beta for 2 reasons: 1) lack of functionality most existing filters have not yet been ported to the new and broader 'function API' the entire buffering mechanism is missing overlapping elements in the processing graph are not yet merged only the localspace has been built. Therefore only userspace FFPF works 2) volatility of interfaces between 1.x revisions the interfaces will be kept stable. For 1.5 we want to stabilize data-access , functions, flowspaces, the inputlanguage, and start/stop control. Of these, data-access is not yet finished and the function API is still in flux. ----- COOL NEW STUFF -------- that said, this release already shows many new features of the 1.5 branch of FFPF: - an expanded input language (it is now boolean complete). you can now also use the NOT and AND operands to specify your flows - faster we have no macro-benchmarks yet, but the new loop should be significantly faster due to a reduction in pointer indirection (cache misses) and function calling at runtime. - a more robust flow start/stop (control) process controlling live elements was very difficult previously because of lack of 'undo' functionality. The new 'flowspace API' allows for more finegrained control, which is especialy useful in case something goes wrong halfway during instantiation. - support for multiple datastream types e.g., the new tcp reconstruction function translates a stream of IP packets into a continuous stream of data. - new functions the filter API has been extended to allow for more generic functions that don't do filtering but mangling, ... 'recieve' and 'transmit' can fetch highlevel input using the berkeley sockets API 'tcpstream' reassembles a tcpstream. - more intensively tested nearly all modules now come with their own unit-tests that are run automatically after each recompile - anything else? I probably missed something. In any case, most old code has gone with more compact and hopefully more readable modules. In the tree you can find many files that are currently unused. These will either be ported shortly (such as the userspace->kernelspace bridging code) or removed. ----- USAGE -------------------- as this is an early beta, there are no example applications yet. All I have is a single Makefile that compiles all the finished code, and executes all unit-test applications at the same time. Run this command, inspect the code and contact us if you have further questions. To be able to find your way here's an overview of the modules : /support contains essential, but nonspecific modules, such as a hashtable, a dictionary, and a packet generator. /filters contains what we now call functions: code that gets called by FFPF to operate on data items (e.g., ip packets) /hooks contains the same. the distinction between filters & hooks is obsolete /core contains the code that is used by all FFPF runtime environments. /core/instance takes care of creating (active) instances of (passive) functions /core/localspace takes care of setting up a dataprocessing graph in a runtime environment. relies on instance /barriers contains code to bridge barriers between different runtime environments (e.g., userspace and kernelspace) /interfaces exports the functions and structures for third-party developers and users /api exports a high-level developer API that calls localspace (possibly through /barriers's bridging spaces) functions /flowspace defines a runtime environment (localspace, kernelspace, ...) /function defines a functional element. all code in /filters and /hooks must adhere to this /parser contains the high-level code to translate a human-readable request into a memory representation that can be fed to /interfaces/api /apps is stale. we have to update these.