On Fri 19 May 2006 14:09, Paolo Lucente wrote: > Hi Peter, > good point (again). pmacct actually lacks of such thing. But it could > be good idea to implement it. The method will need some extra cares in > order to make things work smoothly: a) writes need to be interleaved > in order to avoid one plugin to lock out the other while racing for > the same SQL table; b) with no tags, UPDATEs would become unavoidable. > Here, the almost forgotten "post_tag" directive might be used to tag > things coming from different plugins, thus avoiding "online" UPDATEs. > > Rather than creating a whole new set of "reversed" primitives wouldn't > it be better to create a new config directive ? In the end, the reverse > concept would apply only to direction-specific primitives (ie. TCP/UDP > ports and MAC/IP addresses) and one should not really want to reverse > them singularly (as this would produce spurious tuples). Look at the > following example: > > === > ... > aggregate[db_in]: tag,proto,src_host,dst_host,src_port,dst_port > aggregate[db_out]: tag,proto,src_host,dst_host,src_port,dst_port > aggregate_filter[db_in]: dst net 10.11.0.0/16 > aggregate_filter[db_out]: src net 10.11.0.0/16 > aggregate_reverse[db_out]: true > plugins: pgsql[db_in], pgsql[db_out] > sql_table[db_in]: acct > sql_table[db_out]: acct > post_tag[db_in]: 1 > post_tag[db_out]: 2
Thanks for the quick reply. In-fact this was my alternate suggestion that I was too lazy to write. I favoured the other option as it provides a little more flexibility that someone somewhere might want to use. However, after thinking about it again, I believe you are correct that no-one would actually want to reverse the IPs, but not the ports etc so I think your option is the sanest way to do it. The only question that remains, is how to handle bytes? Ideally I think the schema should be changed/extended to have an bytesin and bytesout column.. What do you think? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
pgpjwD9kXM9FL.pgp
Description: PGP signature
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
