christf / fastd-peer-balance Goto Github PK

mir ist wieder eingefallen warum man das mit dem peer limit doch machen möchte.

dein vorschlag basiert ja auf einer momentanen logischen abschätzung ob man nen peer annehmen soll oder nicht, der schmeisst aber keine raus !
folgender Fall:
3 von 5 gw fallen aus, daran insg 250 router mit 2 fastdverbind jeder. das onverify script schaltet schnell und akzepiert neue verbindungen - massenhaft , bis alle bei den verbleibenden gw sind,

randfall- router haben nur 1 fastd - dann gilt gerade gesagtes
randfall- router haben bis zu 5 fastd (multipliziert grundrauschen) , dann könnte ein router mit allen verbunden sein, und andere mit keinem - am ende statistisch die rechnung aber aufgehen.

40 minuten später sind die gw schon wieder da, aber weil fastd so unkaputtbar ist, wechseln die nicht zurück, daher will man in einem 2. script peer limit in ähnlicher weise gegen aktuelle Situation checken und ggf. fastd sighup neu starten

super ...nice ..

beim ersten drübersehen ist mir aufgefallen das du batctl gwl um 1 verringerst. was passiert denn wenn das null wird, oder sogar minus 1 (bspw. weil "no gateways found" - 1 = 0)
..
der folgende divide by 0 is doof

  gwamount=$(($($BATCTL gwl -H |wc -l)-1))
  connection_average_estimate=$(( net_peer_amount / gwamount ))