[Release] MuchNTP - DOS with NTP amplification

(03-15-2014, 12:15 AM)w00t Wrote:

[To see links please register here]

1. You don't need to comment everything you do. No comments is better than overcommenting.

2. You definitely do not need a class for this.

1. I beg to differ.

2. If you want it to be a linear script, I'm disinclined for the following reason: multiprocessing necessitates the use of at least one function, additionally, I have a checksum function that only needs to be used when constructing packets. Having only 2 functions would be all well and good, but I originally intended to create a GUI for the script (still do, at some point...), so you might see how having
GUI <--> process manager class <--> spammer process
might be more organized.

Also, congrats on S elite

1. The entire industry of software engineering agrees with me. If the comments are so superflous I can safely ignore over 50% of them, its just unneeded clutter, and reduces readability.

2. But why do those functions need to be in a class? If they're function-oriented with a __name__ conditional( as you already have ) you could use it as a module for your further projects.

1. The entire industry of software engineering agrees with me. If the comments are so superflous I can safely ignore over 50% of them, its just unneeded clutter, and reduces readability.

2. But why do those functions need to be in a class? If they're function-oriented with a __name__ conditional( as you already have ) you could use it as a module for your further projects.

(03-15-2014, 03:22 AM)w00t Wrote:

[To see links please register here]

1. The entire industry of software engineering agrees with me. If the comments are so superflous I can safely ignore over 50% of them, its just unneeded clutter, and reduces readability.

2. But why do those functions need to be in a class? If they're function-oriented with a __name__ conditional( as you already have ) you could use it as a module for your further projects.

1.Hardly superfluous, if I didn't comment each number, I would have made constants for them all. I refuse to have "magic numbers" floating around my code. Besides, who is to say they're superfluous? If you instead wanted to adapt this script for some tcp protocol, the comments in creating udpheader would serve you well, if you wanted to use ipv6 instead of ipv4, without the comments there you would need to completely re-write ipheader. And its not like I commented every line, in my opinion the comments are a little lacking. Only the beginning where I need to keep track of what all these numbers mean is it so heavily documented.

2.They are in classes because it helps to keep everything organized, for the same reason you code in c++ instead of c. Anything can be done linearly, it's just harder to keep track of.

(03-15-2014, 03:22 AM)w00t Wrote:

[To see links please register here]

1. The entire industry of software engineering agrees with me. If the comments are so superflous I can safely ignore over 50% of them, its just unneeded clutter, and reduces readability.

2. But why do those functions need to be in a class? If they're function-oriented with a __name__ conditional( as you already have ) you could use it as a module for your further projects.

1.Hardly superfluous, if I didn't comment each number, I would have made constants for them all. I refuse to have "magic numbers" floating around my code. Besides, who is to say they're superfluous? If you instead wanted to adapt this script for some tcp protocol, the comments in creating udpheader would serve you well, if you wanted to use ipv6 instead of ipv4, without the comments there you would need to completely re-write ipheader. And its not like I commented every line, in my opinion the comments are a little lacking. Only the beginning where I need to keep track of what all these numbers mean is it so heavily documented.

2.They are in classes because it helps to keep everything organized, for the same reason you code in c++ instead of c. Anything can be done linearly, it's just harder to keep track of.

(03-15-2014, 12:15 AM)w00t Wrote:

[To see links please register here]

1. You don't need to comment everything you do. No comments is better than overcommenting.

2. You definitely do not need a class for this.

The first point is good advice. You should probably only comment a statement(s) if it/they are not unambiguous. I would try to avoid too many comments.

The second one is just nitpicking for no good reason. If he wants to take an Object-Oriented approach, then allow him to. In theory, you don't really /need/ a class for anything. Well, nothing that I know of, at least. Please, feel free to inform me if I'm wrong.

OOP can be viewed as a more organized way of programming and it can assist with portability (not across computer systems, but rather in terms of programming interfaces and libraries) and re-useability of code.

My point: I see no issue in the usage of OOP in this situation. It's a small script and it really exhibits no noticeable effect on the output from the user's POV. Besides, he's probably accustomed to OOP. It's not a big deal.


On Topic: I haven't personally tried out this script, but it appears to be a good contribution to the forum. Good work.

(03-15-2014, 12:15 AM)w00t Wrote:

[To see links please register here]

1. You don't need to comment everything you do. No comments is better than overcommenting.

2. You definitely do not need a class for this.

The first point is good advice. You should probably only comment a statement(s) if it/they are not unambiguous. I would try to avoid too many comments.

The second one is just nitpicking for no good reason. If he wants to take an Object-Oriented approach, then allow him to. In theory, you don't really /need/ a class for anything. Well, nothing that I know of, at least. Please, feel free to inform me if I'm wrong.

OOP can be viewed as a more organized way of programming and it can assist with portability (not across computer systems, but rather in terms of programming interfaces and libraries) and re-useability of code.

My point: I see no issue in the usage of OOP in this situation. It's a small script and it really exhibits no noticeable effect on the output from the user's POV. Besides, he's probably accustomed to OOP. It's not a big deal.


On Topic: I haven't personally tried out this script, but it appears to be a good contribution to the forum. Good work.

Good job! Could you explain how you would check to see is a server is vulnerable? What would a program do to do this?

Good job! Could you explain how you would check to see is a server is vulnerable? What would a program do to do this?

Could of been done a lot more functional or at least easier, but Good job!