Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsreader4.netcologne.de!news.netcologne.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: bad alloc Date: Sun, 04 Sep 2011 12:03:20 +1200 Lines: 41 Message-ID: <9cfti9FsstU5@mid.individual.net> References: <28a1b207-f29e-4d7d-81ca-490aa64bb808@z18g2000yqb.googlegroups.com> <214b61f9-0a26-446d-9bcf-6da7d70326d9@k15g2000yqd.googlegroups.com> <38b94512-ef13-4168-b057-f095ed7c91b7@c19g2000yqe.googlegroups.com> <9dbad43a-f341-44ac-b3cb-14cb8f3eb909@l2g2000vbn.googlegroups.com> <6bfba27a-a5bd-42df-b3b9-d1d393958665@fd21g2000vbb.googlegroups.com> <9cb8rmFfcoU1@mid.individual.net> <64024153-4384-44d8-aec8-b097c44e848e@t5g2000yqj.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net pGQ5Euc5RyJa3ieAvBBcUQCI5JD8j6U9KdSKCKXUHYU5md2veZ Cancel-Lock: sha1:2u6PKS94KDmM1uHz9BCgVxpgaRc= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: <64024153-4384-44d8-aec8-b097c44e848e@t5g2000yqj.googlegroups.com> Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:9717 On 09/ 4/11 11:20 AM, James Kanze wrote: > On Sep 2, 6:45 am, Ian Collins wrote: >> On 09/ 2/11 04:37 PM, Adam Skutt wrote: > > [...] >> I agree. On a descent hosted environment, memory exhaustion is usually >> down to either a system wide problem, or a programming error. > > Or an overly complex client request. Not spotting those is a programming (or specification) error! >> If you require an application to be "robust" then you can use >> an external entity to manage and if necessary, restart it. >> This is common practice for system processes. > > That's the correct response to a programming error or a system > wide problem. For a request which is part of a DOS attack, it > seems to be playing into the attacker's hand, and for a simply > unreasonable client request, it does seem unnecessary to abort > all other client connections. What's wrong with just responding > with an "insufficient resources" error? No, it doesn't. Which is why it's not a good idea to allocate an arbitrarily large chunk of memory in response to an external request. Where overly complex requests are easily to discard, the more insidious DOS attacks are those that make many, apparently reasonable, requests. To protect against those, finer resource limits (such as a finite set on input buffers) than the size of the heap should be used. > [...] >> Indeed, robustness goes beyond a single application. > > That's why robust servers run on dedicated machines (where they > are the only "application"). Indeed. That's why I run mine in their own container, with dedicated system resources. Dedicated machines are so last century! -- Ian Collins