[IDEA] Dynamic priority process

[mk01]

(26th Jul, 2013 11:17 PM)belese Wrote:  ps :
seems there's a bug in ipconnection bridge,
for transmission, it didn't detect end of connection now.

belese, as always too late, but still maybe you use in future.

with standard netfilter it's easy as:

Code:

root@media:/var/log# iptables -L -n -v
Chain INPUT (policy ACCEPT 292 packets, 32127 bytes)
pkts bytes target     prot opt in     out     source               destination        

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 165 packets, 31081 bytes)
pkts bytes target     prot opt in     out     source               destination

normally those chains are meant for firewalling / routing, but we can downsize it's function to just count packets / bytes.

so if you want to monitor for instance port 22 (ssh), add a rule to ACCEPT

Code:

iptables -I INPUT -j ACCEPT -p tcp --dport 22

with result

Code:

root@media:/var/log# iptables -L -n -v
Chain INPUT (policy ACCEPT 473 packets, 50461 bytes)
pkts bytes target     prot opt in     out     source               destination        
   17  2053 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 289 packets, 49084 bytes)
pkts bytes target     prot opt in     out     source               destination

you can poll this numbers with grep or let it send to a file descriptor (opened by variant of your python script which listens to the xbmc events). from this point of view, it;s the same. you just use LOG policy instead of accept.

and to get rid of calculations in the bridge script, you can directly define priority targets directly in netfilter, what means according to current bandwidth (not only absolute pkt/bytes numbers) to MARK and then LOG.

so at the end you would have in input chain four rules, with target MARK, described not by port number but RATE, followed by one rule to LOG, which would on some transfer send a human readable text line MARKed already according your priority split.

so the bridge daemon would be just a loop with case and initctl emit.