Yay! I'm glad to hear that it was a temporary issue. I've been sitting here for 
the last hour thinking "I'm going to have to start this website entirely over 
again, and I'm almost done with it", as I know that its going to look like a 
bunch of "automated requests" (lots of small requests quite often from users 
who are going to be on cell phones, and therefore on 3G and Edge IP address 
pools that I have no control of or documentation on, but for which I know there 
aren't many). I wish Google would actually say something about where they are 
going in this direction, though :(.

Out of curiosity, how are you currently dealing with this problem? I mean 
"currently" as in "without/before App Engine"? App Engine is quite unique in 
being "free" (and I don't think that's at all a feature). For example, if you 
want to start burning cash out of my pocket, start downloading files rapidly 
from my CDN (where I have to pay for bandwidth), or start rapidly uploading 
things to my S3-backed website (where I have to pay for storage). What were you 
using before App Engine, and how did they solve this same problem?

Where App Engine is not unique, though, is being in a position where "[my] app 
potentially sits alongside [your] application". This is how it always worked 
with bandwidth (just fundamentally and in the global sense) and how it usually 
works with managed web hosting. It also is becoming more and more the case with 
cloud computing. To stare at Amazon for a second: everyone is sharing the power 
of SimpleDB, the servers of EC2, and the storage of S3. And yet, the cloud 
doesn't end when someone attempts to DOS one of the applications that use these 
services. This is why I say "I don't even understand the need for this". ;P

Though, what is really getting me here, is that "abuse" can't be defined from a 
technical perspective. Abuse has nothing to do with how many IP addresses are 
contacting my website in how short a period of time: it has to do with whether 
my traffic is legitimate or not. Telling me what these limits are doesn't make 
the limitation much more reasonable. I've seen a number of other service 
providers try to go down this path, and it just doesn't work: getting five 
e-mails in a day from someone I don't like is irritating, but getting five 
e-mails from someone else might be pleasant (and in fact talking to them might 
be the reason I use e-mail).

As a quick apropos example, let's take BuddyPoke: the famous case of "popular 
Facebook application on App Engine". Now, I don't know how BuddyPoke is 
configured (and it doesn't really matter, as BuddyPoke need not be the exact 
exemplar), but the most common way (for various reasons) to setup Facebook 
applications is to receive HTTP callbacks from Facebook, to which you return 
"FBML" (HTML with embedded tags for things like "a small picture of user X"). 
All of your requests are going to come from the same few IP addresses (which 
you don't have any control over), and they are going to come extremely rapidly 
(well, if you're lucky). Putting any limit at all on "requests per ip address 
per hour" is therefore saying "do not write BuddyPoke". ;P

Another way of putting it: while I understand why someone would want protection 
from the things you are discussing, this doesn't seem like a viable way to get 
it. I would also question whether someone really needs to live in an air tight 
bubble in order to protect themselves from cigarette smoke (especially if their 
airtight bubble just caused them to suffocate ;P).

-J



From: Paul Kinlan 
Sent: Sunday, November 16, 2008 11:22 PM
To: google-appengine@googlegroups.com 
Subject: [google-appengine] Re: 403 - sorry.google.com/sorry - your query looks 
similar to automated requests


I actually think it was a temporary glitch, I have not seen it at all since 
when we first reported it.

I am in the same boat as Adam, I designed my page to make lots of simultaneous 
request (via an xmlhttprequest) instead of doing all the hard work in the main 
web page...  Its a hard one, because if google tell us the thresholds for 
triggering this then it is open to abuse up unitl that limit.  You can stop one 
person from abusing the site by blocking them from making requests over this 
threshold, how would you do it for 1000 machines from different networks 
hitting your site to just below the threshold regularly.

To get to Jays argument.  although I am not keen on it, as per my original 
email, I have had time over the weekend to think about it.  I think we all need 
protection from malicious use, after all, everything on this service will be 
directly monetisable (above the free quota) and with the services that I run, I 
don't want to spend money on people who are not interested in my site. I would 
however like some control over what would be blocked, after all I will be 
exposing API's to clients when the GAE is out of "beta" and if it was a 
traditional unix host (for instance) I would have control over the ip 
addresses/ranges that have access to my site.  The point I was making about 
unfairly using a shared system is that unlike a traditional host where you have 
own machine on the network, GAE is not like that, your app potentially sits 
alongside my application, and if for some reason your site is getting hit by 
bots, it could easily mean that my site is affected.  Obviously, I don't know 
Google infrastructure and it could be vast array of machines already set up for 
the GAE so the likleihood of you affecting my site may be minimal.

Anyway, i think this issue may have been a storm in a tea cup (unless anyone is 
still get this error).

Paul.





2008/11/17 Adam <[EMAIL PROTECTED]>




  On Nov 17, 1:07 am, "Jay Freeman \(saurik\)" <[EMAIL PROTECTED]>
  wrote:

  > :( I don't even understand "the need for this".



  If/when I get to the point of paying for quota overages, it would be
  nice if there was built in protection from someone setting up a cron
  process to essentially drain money from my bank account by creating
  'fake' traffic.

  I'd just like some clarity on how this test works, so I don't trigger
  it with AJAX calls on my page.  CPU warnings made me thing 20 quick
  calls were better than 1 or 2 slow calls, but if that shuts down my
  app for a user after 20 seconds of navigation on the map maybe it's
  not.



  A






--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to