some thoughts about ulogd2 architecture

1 files changed, 62 insertions, 0 deletions

diff --git a/ARCHITECTURE b/ARCHITECTURE
new file mode 100644
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)
+