On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
Le 13 mai 05, � 07:19, Niclas Hedhman a �crit :
Can you explain this a bit further? Because I have no clue what you think is the actual problem.
I think Vadim sees a potential denial of service attack, if your system allows one to generate images of a very large size.
Our test shows that; 1. Image generation is in the sub-second range, even for really large images. We hit the server 100 concurrent requests of sizes from 500-1500 px, and couldn't register any particular load.
I used 4096 :-) Not sure if it will accept larger image size as well.
2. No matter how big sizes you generate, the bandwidth that the system is
connected to will 'run out' way before the CPU gets bogged down. AFAIK, if I have a lot more bandwidth than you, I should be able to DoS your
system.
DoS is not necessarily overloading CPU - overloading your channel is DoS too. If your channel has lots of bandwidth, then DDoS is the way to go :-)
3. If the image is too large then an OutOfMemoryError is the result (in 2ms)
which Tomcat recovers from.
So that means picking the right size of image... Not sure how healthy large does of OOME, though.
In any event, I can't see this being anything different from any CPU intensive webapps, and why it is any different from a complex XSLT transform. But I do like to ehar from anyone who got such ideas.
XSLT transformrs usually do not have bandwidth / computational dependencies on the request parameters.
On your place, I personally would not accept arbitrary image size in the URL - even if I have it in the URL. I would limit access only to image sizes I want to allow. This reduces chance for abuse - and increases chance for cache hit (suppose you have zoom control with 5 poisitions and 1000 positions: latter have higher probability of cache hit, former - higher probability of cache miss).
Since this came up, I will introduce a "max-size" parameter, with a default in the 1000x1000 or so range.
Good idea.
OT: Why square? Aren't photos ratio 4:3 or some such?
Vadim
