some thoughts about ulogd2 architecture

diff --git a/ARCHITECTURE b/ARCHITECTURE
new file mode 100644 (file)
index 0000000..20976b0
--- /dev/null
+++ b/ARCHITECTURE
@@ -0,0 +1,62 @@
+Architecture of ulogd2
+
+1. Applications
+
+1.1 ipfix exporter:
+- receives ctnetlink messages for 'delete' events
+- creates two ipfix flow records according to a fixed template
+- sends ipfix flow record over tcp, udp or sctp (ssl support!)
+- optional
+       - maintain rules about which flows to export
+       - support multiple outbound connections to multiple collectors
+
+
+1.2 ipfix collector:
+- receives ipfix messages based on any kind of template
+- aggregates flow records in in-memory database
+- can export flow records based on plugins
+
+
+2. generalization:
+- flow metering (input) plugins
+       - flow based
+               - ctnetlink / ctacct
+               - flowcache?
+               - ipfix packets
+       - packet based
+               - ulog
+               - PF_PACKET
+- flow filtering plugins
+       - aggregator (like net-acct)
+       - real filter
+       - grouping
+- flow exporting (output)
+       - mysql
+       - ipfix packets
+
+3. random ideas:
+- stackable plugins
+       - admin defines order of stack
+       - any plugin looks the same to the core
+       - no difference between input, output, filter
+       - multiple stacks can be configured at the same time
+       - attributes of stackable plugin
+               - name
+               - config keys
+               - itype (null|packet|flow)
+               - otype (packet|flow|null)
+               - input function 
+                       - gets data from underlying module
+                       - not existing (NULL) for real acquisitors
+                       - return value: chain of ulog_iret_t
+               - signal handler
+       - core exports functions to register filedescriptors for main
+         select loop (for in/out fd's)
+       - output plugins at very end of chain specify which field_id's
+         they require as input.  this template is then handed backwards
+         up the chain[tree] to the input plugins
+
+
+- problems:
+       - multiple interpreters can return same value (i.e. sport/dport)
+