Looks for DHCPACK in logs.
Parses MAC from it.
Checks with a http server which responds with a pass/fail.
If http response is success, sends a RADIUS packet for Authentication.
Apart from this, I need to monitor MACs that have failed and also those that have passed continuously.
What I am worried about in my non-threaded model is that when several DHCPACKs come at the same time and one request takes a little longer than expected, it will block all the other MACS in queue => Hence threads to do the API and RADIUS checks.
As mentioned in my earlier post , pumping 10 DHCP acks into the log files saw 10 threads being created simultaneously. BTW, not implemented the radius part yet. ONly the pass/fail part is being tried.
Each response takes roughly 1 second in the network normally. The first thread does that but then it progressively worsens . The 10th takes 8 seconds. The reason I *think* is how the threads are scheduled and the join. From what I have read it looks like join blocks the other threads. So if you look at the 10th thread, it is blocked by the 9 threads before by their joins.
I even tried detach instead of join. Again, it progressively worsens as it reaches the 10th thread. I dont know why.
I am looking at ways to for each http call to take roughly the same time and finish and be able to have a hash in the main thread w the status for each MAC I have encountered.
In reply to Re^5: Should I use threads? Perl/DHCP/Radius
by MonkeyMonk
in thread Should I use threads? Perl/DHCP/Radius
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |