Should disallow very large rolls (e.g. 10000d100)
Closed this issue · 7 comments
GoogleCodeExporter commented
Rolls that would place too high load on roller should not be allowed.
Original issue reported on code.google.com by shooshpa...@gmail.com on 2 Nov 2009 at 10:15
GoogleCodeExporter commented
Original comment by shooshpa...@gmail.com on 2 Nov 2009 at 10:18
- Added labels: Priority-High
- Removed labels: Priority-Medium
GoogleCodeExporter commented
Patch that kinda fixes it. Doesn't do much to stop people writing
1d6+1d6+1d6+1d6...
a few thousand times, but stops people writing 999999d6. Feel free to expand on
it.
I also saw a class 'AbstractRollingMethod' but I don't think it's used, so I
didn't
adjust it. (I didn't change any DitV stuff either, since it seems to use a
different
set of classes and I wasn't sure whether it was going to be changed or not.
Original comment by trent.ba...@gmail.com on 2 Nov 2009 at 1:48
Attachments:
GoogleCodeExporter commented
I also used checked exceptions, which in retrospect might have been better as
unchecked exceptions, to avoid polluting the codebase with 'throws' markers.
Original comment by trent.ba...@gmail.com on 2 Nov 2009 at 11:54
GoogleCodeExporter commented
I've got an idea: we can place three global limits on rolls:
1) Maximum number of Random#nextInt() calls per roll (e.g. 10000) - to limit
CPU load
during the roll itself.
2) Maximum length of roll request string (e.g. 200) - to limit CPU load when
parsing
roll request.
3) Maximum length of roll result string (e.g. 200) - to limit outgoing
bandwidth.
How does it look to you?
Original comment by shooshpa...@gmail.com on 4 Nov 2009 at 9:47
GoogleCodeExporter commented
Sounds good; they're all reasonable limits.
Original comment by trent.ba...@gmail.com on 4 Nov 2009 at 12:11
GoogleCodeExporter commented
Original comment by shooshpa...@gmail.com on 4 Nov 2009 at 2:51
- Changed state: Started
GoogleCodeExporter commented
Phew! After two refactorings was able to fix this in an acceptable OOP style.
Original comment by shooshpa...@gmail.com on 8 Nov 2009 at 10:16
- Changed state: Fixed