For this second, you can set an A record to 74.125.113.121. But google.dns.tancee.com will keep available if this IP got banned.
So when Chinese can't visit your web site, you can ping google.dns.tancee.com to see if there is a new available IP, and change your A record again. Hope this would be helpful. 2009/4/12 kiss242 <kiss...@gmail.com> > > I suggest never do that, since google.dns.tancee.com is not your own > domain name, what if the owner/cracker directs it to another malicious > page? > You'd better find an google ghs ip, and then make an A record to it. > > I think the best way is that Google provides unique static ips. > > http://groups.google.com/group/google-appengine/browse_thread/thread/78c7b96fd653f24b > > > On 4月10日, 下午5时52分, 风笑雪 <kea...@gmail.com> wrote: > > You can try this CNAME to instead of ghs: google.dns.tancee.com > > My website(http://gae.keakon.cn/) is ok by visiting from China. > > > > 2009/4/10 T.J. Crowder <t...@crowdersoftware.com> > > > > > > > > > Hi Wally, > > > > > Happy to help (if I did). > > > > > > ...you have certainly > > > > covered all the technical bases of implementing a proxy. > > > > > Oh, I very much doubt it. :-) (BTW, I don't know where that "six" > > > came from in my earlier post. You'll incur 2-3 times, not 2-6 times, > > > as much transfer on requests for dynamic content through the proxy.) > > > > > > 1. I have experienced being blocked by the app engine (try again in > an > > > > hour etc.), so I could reasonably assume that it would be likely that > > > > a lot of traffic coming from one source may be blocked. > > > > > Perhaps Brett Slatkin or someone else from Google's technical wing > > > could comment on this. > > > > > I don't know about AppEngine, but Google does place rate limits on end > > > users' use of various apps they provide (such as Google Groups!), and > > > so this is something to be aware of. But I'd be surprised if those > > > rate-limits are naive enough to be confused by requests from a > > > properly-configured proxy. A request from a properly-configured proxy > > > includes the original source of the request as well as the proxy (or > > > proxies) through which it's passed.[1] Proxies are widely used across > > > the web, including by ISPs with hundreds of thousands of end users or > > > more. To lump them all together under one rate limit (or at least > > > under a rate limit intended for individuals) would be inappropriate. > > > > > [1]http://tools.ietf.org/html/rfc2616#section-14.45 > > > > > This also applies to your points 2 and 3; the original request's > > > origin is preserved across the proxy (in the normal case; we're not > > > talking about intentionally non-compliant -- but useful! -- proxies > > > such as anonymizers and the like). In any case, the adsense stuff > > > won't go through your proxy, remember that the script comes directly > > > from googlesyndication.com. > > > > > > Google has also said nothing about the China block, which again means > > > > to expect the worst. > > > > > Wally, I'm quite certain that any time China blocks the whole of > > > AppEngine (which they don't appear to be doing currently, from other > > > comments), Google is aware of it very quickly and does everything they > > > reasonably can to clear up the problem working through channels with > > > the appropriate Chinese officials. They cannot afford to be closed to > > > China. Now, the degree to which they'll succeed largely depends on > > > the Chinese government. AppEngine is a bit of a problem for them, > > > it's just ridiculously easy to throw together an app that provides a > > > way for Chinese citizens to break through the great firewall and get > > > unfiltered information. I'm not surprised the whole of AppEngine was > > > blocked for a time last year, and I'm not surprised it got unblocked > > > -- presumably the result of discussion and negotiation between the > > > Chinese government, U.S. government, and Google. If Google haven't > > > commented on the situation, FWIW I wouldn't take that as evidence of > > > their not being concerned about and actively engaged in addressing the > > > problem. Public statements can sometimes cause trouble in sensitive > > > negotiations. But hey, not like I'm an expert on international > > > business and government relations. ;-) > > > > > And I didn't mean to get into the politics; mainly I was trying to > > > address your question about how to go about getting a proxy set up. > > > > > Good luck, > > > -- > > > T.J. Crowder > > > tj / crowder software / com > > > Independent Software Engineer, consulting services available > > > > > On Apr 10, 1:08 am, WallyDD <shaneb...@gmail.com> wrote: > > > > Hi TJ, > > > > > > That really is an amazing post. I'm impressed, you have certainly > > > > covered all the technical bases of implementing a proxy. > > > > > > My biggest concern is that Googles behaviour is unpredictable and I > > > > not entirely sure how well they will respond to something like this > > > > being implemented. > > > > > > 1. I have experienced being blocked by the app engine (try again in > an > > > > hour etc.), so I could reasonably assume that it would be likely that > > > > a lot of traffic coming from one source may be blocked. > > > > 2. A large portion of the revenue comes from Google adsense/adwords. > > > > Google uses a variety of mechanisms to check for invalid clicks, so > > > > all the clicks coming from one source would no doubt raise some red > > > > flags. > > > > 3. The traffic statistics would be almost useless (there is probably > a > > > > workaround... but a lot of work). > > > > 4. Google has deliberately and intentionally blocked traffic > > > > originating from Sudan, Syria, Cuba, Iran and North Korea(not really > > > > sure if they have internet there). From the legal discourse I have > > > > read it would appear google is obligated to block any proxies where > > > > traffic is coming from these countries. I don't really understand > this > > > > one as the USA changed their political administration in January 2009 > > > > and the block went in two weeks later. There has to be some politics > > > > behind this which I am unaware of. Google has decided to say nothing > > > > on this subject so I can only assume the worst. > > > > > > Google has also said nothing about the China block, which again means > > > > to expect the worst. > > > > I am also far from convinced that Google has figured out China (like > a > > > > lot of western companies). From the look of their developer > bloghttp:// > > >www.developer.googlechinablog.com/, only 16 people read this as > > > > the RSS feed. > > > > I can't really expect any Chinese to have faith in Google with not > > > > only that their country has blocked, but more importantly that > google > > > > itself has actively blocked other countries. > > > > > > Google will do what Google wants to do and fail to communicate. I > > > > can't see this strategy doing anything other than annoying the > Chinese > > > > further. And back to China I go next week (luckily on unrelated > > > > business). > > > > > > And TJ, I like your post, if I can get some (positive) answers I will > > > > be putting in a proxy just as you have outlined. Keep up the great > > > > work. > > > > > > On Apr 9, 10:35 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote: > > > > > > > Hi Wally, > > > > > > > Sorry to hear about the block. > > > > > > > > The internet is indeed a funny place. > > > > > > I did respond with a question on how to set this up but have > received > > > > > > no answer? > > > > > > > > Any ideas anyone? > > > > > > > Setting up a proxy server is a non-trivial task (I'm not saying > it's > > > > > hard, just non-trivial) so you're not likely to get a lot of > dedicated > > > > > help for it here. May be worth seeking out other newsgroups for > the > > > > > technical details (if you haven't already!). > > > > > > > Most commercial-grade web software such as Apache[1] or nginx[2] > can > > > > > be set up to proxy, and there are several dedicated proxy packages > as > > > > > well (such as Squid[3]). I've been hearing very good things about > > > > > nginx the last year or so, but have virtually no direct experience > > > > > with it (and not that much experience setting up proxies at all, so > > > > > take all of this with a grain of salt). > > > > > > > [1]http://httpd.apache.org/ > > > > > [2]http://nginx.net/ > > > > > [3]http://www.squid-cache.org/ > > > > > > > But since you'll need a hosting provider of some sort for the > proxy, > > > > > and it sounds as though this is going to be your main reason for > > > > > having that other hosting service, it may be worth considering > > > > > approaching hosting providers who will set up and maintain the > proxy > > > > > for you, rather than doing it yourself. I searched for "proxy > > > > > hosting" and there's a whole industry out there you can tap into. > It > > > > > depends on whether this is something you want to add to your set of > > > > > skills. Naturally, you'll want to be sure that the proxy hosting > > > > > company itself isn't blocked in China! Given what they do, I > suspect > > > > > a fair number of them are, but the censors can't keep on top of all > of > > > > > them, and you can switch as necessary (the joys of proxying!). > > > > > > > A downside of the proxy approach is that you'll end up paying > anywhere > > > > > from twice to six times as much for at least some of your site's > > > > > traffic -- the parts that can't be cached. Say you host the proxy > at > > > > > Acme Hosting Company. Where before your traffic costs on a request > > > > > for dynamic content were: > > > > > > > * Inbound cost at AppEngine (receiving request from end user's > > > > > browser) > > > > > * Outbound cost at AppEngine (sending reply to end user's browser) > > > > > > > with a proxy you'll be paying: > > > > > > > * Inbound cost at Acme (receiving request from end user's browser) > > > > > * Outbound cost at Acme (sending request to AppEngine) > > > > > * Inbound cost at AppEngine (receiving request from proxy) > > > > > * Outbound cost at AppEngine (sending reply to proxy) > > > > > * Inbound cost at Acme (receiving reply from AppEngine) > > > > > * Outbound cost at Acme (sending reply to end user's browser) > > > > > > > So you'll need to shop around with that in mind. Again, that's > only > > > > > the dynamic content; if the proxy can satisfy the request from > cache, > > > > > it will, and so you wouldn't end up paying AppEngine transfer costs > > > > > (or CPU time costs) on that particular request at all. > > > > > > > Some suggestions related to that: > > > > > > > * Provide a transparent redirect mechanism or some such for users > who > > > > > can go direct, so avoid putting unnecessary load and throughput on > the > > > > > proxy. > > > > > > > * Be sure that your site's content is as cacheable as possible (but > > > > > this is always a good idea). The more cacheable your site, the > faster > > > > > it seems to be, because there's a fair bit of caching that goes on > out > > > > > in the cloud if you let it; caching doesn't only happen at the end > > > > > user's browser. > > > > > > > * Make sure all of the > > > > ... > > > > 阅读更多 >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
