Closed jdoe7865623 closed 2 years ago
Hi! I thought about something similar too, to better inform the user about the results and thus efficiency. So I had one more thought - maybe it should somehow specify summarised response codes and something like closed / rejected connections. And maybe some efficiency coefficient. No idea how to calculate it, but it would be great - e.g. to try different VPNs / servers. What do you think? (yes, I'm willing to participate in coding, just trying to cooperate because I found your pr which seems close to something I would do, so I decided to write here first).
Also had an idea to replace those tons of duplicated repetitive messages about starting a thread for a target like
2022/04/06 17:07:48.414177 http.go:147: Attacking **sample**
2022/04/06 17:07:48.414892 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415018 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415130 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415163 http.go:147: Attacking **sample**
with something more combined and shorter, like maybe
2022/04/06 17:07:48.414177 http.go:147: Attacking (30 threads) https://**sample**
2022/04/06 17:07:48.414892 http.go:147: Attacking (20 threads) https://**sample**
etc
would be much shorter and easier to follow
Hi! I thought about something similar too, to better inform the user about the results and thus efficiency. So I had one more thought - maybe it should somehow specify summarised response codes and something like closed / rejected connections. And maybe some efficiency coefficient. No idea how to calculate it, but it would be great - e.g. to try different VPNs / servers. What do you think? (yes, I'm willing to participate in coding, just trying to cooperate because I found your pr which seems close to something I would do, so I decided to write here first).
Fair enough; we can't summarize by response codes since there are different protocols involved - not only HTTP. This is why I thought of the five metrics you can see in the table as a common denominator of sorts. Collecting these metrics from all supported jobs is still a WIP.
You may define "efficiency" as a ratio between the responses received and requests attempted (or sent). But this is somewhat subjective (what if the target is down due to the swarm activity? :), so I decided to start with plain stats. I'm open to suggestions, though.
Also had an idea to replace those tons of duplicated repetitive messages about starting a thread for a target like
2022/04/06 17:07:48.414177 http.go:147: Attacking https://kupiprodai.ru 2022/04/06 17:07:48.414892 http.go:147: Attacking https://kupiprodai.ru 2022/04/06 17:07:48.415018 http.go:147: Attacking http://kupiprodai.ru 2022/04/06 17:07:48.415130 http.go:147: Attacking https://kupiprodai.ru 2022/04/06 17:07:48.415163 http.go:147: Attacking http://kupiprodai.ru
with something more combined and shorter, like maybe
2022/04/06 17:07:48.414177 http.go:147: Attacking (30 threads) https://kupiprodai.ru 2022/04/06 17:07:48.414892 http.go:147: Attacking (20 threads) https://rudos.ru etc
would be much shorter and easier to follow
Yeah, those are not super-helpful at this point. The runner does not know much about the specific job config, though, thus we log this stuff from within the jobs in coroutines. That causes a barrage of identical messages. Feel free to submit a PR if you come up with a smart suggestion :)
ok, yep, I'll try. I have several small ideas to start from.
This is a work in progress for feedback, migration to the new reporter is not done yet.
The new console stats will tentatively look as follows: