Recommend
1 
 Thumb up
 Hide
20 Posts

Mechs vs. Minions» Forums » General

Subject: How many did it take? rss

Your Tags: Add tags
Popular Tags: [View All]
Hans Moleman
United States
Chicago
Illinois
flag msg tools
I was saying boo-urns
badge
Avatar
mbmbmbmbmb
/////
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
elac yenwod
United States
Arizona
flag msg tools
//
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Maui Chris
United States
San Ramon
California
flag msg tools
Valentino Rossi Fan
badge
get this ball
Avatar
mbmbmbmbmb
///
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Thomas W
United States
Alpharetta
Georgia
flag msg tools
badge
Avatar
mbmbmbmbmb
/// and //
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Bart Rachemoss
United States
Silver City
New Mexico
flag msg tools
Science is the belief in the ignorance of experts.
Avatar
mbmbmbmbmb
///

Funny that extra slashes were needed to get around a slashdot effect.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Jesse W.
United States
Utah
flag msg tools
Game-playing Meowstic
Avatar
mbmbmbmbmb
What does this even mean?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Philip Moody
Switzerland
flag msg tools
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////....ad infinitum.


I had to F5 1000 times, turn my computer on and off six times, throw my computer out the window, build a new computer from random bits of electronics scattered about my hotel room, wrap myself in tinfoil, and sacrifice a chicken, and then it worked! goo
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Jon Visser
United States
Minnesota
flag msg tools
The very last time I tried, it only took once.

And that only happened after banging my head against a door for 4 hours before doing a quick Google search of "Riot games checkout" for the win. That was one of the worst glitches a company could do. This game better not be a flop.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Kristo Vaher
Estonia
Tallinn
Harjumaa
flag msg tools
badge
Avatar
mbmbmbmbmb
It's amusing that I know why this actually worked. But kudos for discovering it, guys
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Jorgen Peddersen
Australia
Sydney
New South Wales
flag msg tools
Avatar
mbmbmbmbmb
BDSb wrote:
What does this even mean?

Users of the NA store were adding slashes to the back of the URL to get better access while the site was swamped.

 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Bart Rachemoss
United States
Silver City
New Mexico
flag msg tools
Science is the belief in the ignorance of experts.
Avatar
mbmbmbmbmb
Slashdoctor wrote:
It's amusing that I know why this actually worked. But kudos for discovering it, guys

This is an interesting question. Someone said it allowed the page request to go through to the server without getting a cached copy along the way. This makes some sense. If you use a url that no one else (nearby) has used then it will be a cache-miss and you will get a fresh page from the server. Web servers are usually configured to combine multiple slashes into a single slash so by adding slashes you are using a slightly different name for the page you want.

But since this trick worked, it seems like the bottleneck wasn't the riot games servers but rather some network infrastructure that was doing the caching. Perhaps the caching kicked in automatically due to the heavy demand. But it makes no sense to cache shopping carts since each person should have their own one so a cached version of someone else's cart isn't going to work. I wonder if this caused the unexpected network problems?

There could have been a lot of needless thrashing if the network was trying to serve up cached shopping cart pages. I'm guessing that could have caused a bunch of infinite loops (with browsers re-requesting the same page since the one they were getting from the cache was bogus).

I may not have all of the details right but some salient points are:

1) the cache must be very screwed up if the non-cached versions of the pages come up faster than the cached versions

2) Shopping cart pages cannot be usefully cached. If cached versions were being delivered then something was very wrong.

3) The riot games servers were able to handle the demand (at least the demand that was throttle by the messed up caching)

2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Kristo Vaher
Estonia
Tallinn
Harjumaa
flag msg tools
badge
Avatar
mbmbmbmbmb
BitJam wrote:
Slashdoctor wrote:
It's amusing that I know why this actually worked. But kudos for discovering it, guys

This is an interesting question. Someone said it allowed the page request to go through to the server without getting a cached copy along the way. This makes some sense. If you use a url that no one else (nearby) has used then it will be a cache-miss and you will get a fresh page from the server. Web servers are usually configured to combine multiple slashes into a single slash so by adding slashes you are using a slightly different name for the page you want.

But since this trick worked, it seems like the bottleneck wasn't the riot games servers but rather some network infrastructure that was doing the caching. Perhaps the caching kicked in automatically due to the heavy demand. But it makes no sense to cache shopping carts since each person should have their own one so a cached version of someone else's cart isn't going to work. I wonder if this caused the unexpected network problems?

There could have been a lot of needless thrashing if the network was trying to serve up cached shopping cart pages. I'm guessing that could have caused a bunch of infinite loops (with browsers re-requesting the same page since the one they were getting from the cache was bogus).

I may not have all of the details right but some salient points are:

1) the cache must be very screwed up if the non-cached versions of the pages come up faster than the cached versions

2) Shopping cart pages cannot be usefully cached. If cached versions were being delivered then something was very wrong.

3) The riot games servers were able to handle the demand (at least the demand that was throttle by the messed up caching)



Definitely the middle-man issue for caching. And actually cache not being used for shopping carts is thinking that is a little outdated. Smart caching systems have no problems also caching user behavior by keeping user data and shopping workflow as two different services. Technically it does not matter WHO is making a purchase until money is transferred.

And because almost everybody was ordering exactly one item of the same game in their shopping cart, cache had no problems kicking in. Other URL's worked, because cache key (and thus resource) changed.

What surprised me though is that they even had this "//" trick working. This is actually a security hole that they should patch. This can lead to some nasty Denial of Service attacks if you have URL's that you can infinitely generate to bypass cache and still serve actual service content as a result instead of immediate 404's.

(then again they were fine by having customers DoS them anyway)
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Bart Rachemoss
United States
Silver City
New Mexico
flag msg tools
Science is the belief in the ignorance of experts.
Avatar
mbmbmbmbmb
Slashdoctor wrote:
And actually cache not being used for shopping carts is thinking that is a little outdated. Smart caching systems have no problems also caching user behavior by keeping user data and shopping workflow as two different services. Technically it does not matter WHO is making a purchase until money is transferred.

I don't understand this. ISTM it is never a good idea to mix up the shopping carts of different customers. I've never seen a situation where shopping carts are differentiated by contents instead of customer (even if the customers are anonymous until checkout). My guess is that the cache was ignoring whatever information channel was used for the session id which keep customers separate. If it was working properly then my session id would differentiate my shopping cart from everyone else's and would generate a cache-miss without needing a different url. Also, if it was working properly then a cache-hit would always be faster than a cache-miss.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Kristo Vaher
Estonia
Tallinn
Harjumaa
flag msg tools
badge
Avatar
mbmbmbmbmb
BitJam wrote:
Slashdoctor wrote:
And actually cache not being used for shopping carts is thinking that is a little outdated. Smart caching systems have no problems also caching user behavior by keeping user data and shopping workflow as two different services. Technically it does not matter WHO is making a purchase until money is transferred.

I don't understand this. ISTM it is never a good idea to mix up the shopping carts of different customers. I've never seen a situation where shopping carts are differentiated by contents instead of customer (even if the customers are anonymous until checkout). My guess is that the cache was ignoring whatever information channel was used for the session id which keep customers separate. If it was working properly then my session id would differentiate my shopping cart from everyone else's and would generate a cache-miss without needing a different url. Also, if it was working properly then a cache-hit would always be faster than a cache-miss.


Not saying that they are doing it this way, but that's my best guess. And it's not that uncommon an approach, we're using it on our systems to increase customer experience speed and it does it automatically. 99% of new orders, when a new item is released, always are just made for that one single order, so shopping cart itself is the same for all of those 99% customers. Stock status is checked only once Checkout starts (and this alone can invalidate previous cache as well, using concept called cache tagging).

And my guess that they are using it comes from the fact that they don't have any shipping information in shopping cart unless you specifically add it. It becomes part of the process only at that point. Thus? It seems to be cache.

Of course how things actually broke can only be clarified by Riot's guys, but my best guess is that this was a cache-read from the same bottlenecked resource that was under immense load (one of the indicators was also that their other static resource delivery broke down after a while).
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Sataranji
United States
Twin Cities
Minnesota
flag msg tools
badge
Avatar
mbmbmbmb
During the initial rush of ordering yesterday I poked around a bit and found that the underlying network error - the reason for the "Uh Oh" page - was:

HTTP/1.1 522 Origin Connection Time-out

The Riot Games site uses Cloudflare as its CDN (Content Delivery Network). According to their support documentation on HTTP 522 errors one of the causes can be that "The origin server was too overloaded to respond."

https://support.cloudflare.com/hc/en-us/articles/200171906-E...

Adding additional slashes to the URL in an attempt to bypass the caching layer (the CDN) and route the request directly to the origin results in even more load on the origin server. So this "trick" possibly made the situation worse for others trying to order.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Kurt B
United States
Kansas
flag msg tools
Avatar
mbmbmbmbmb
Slashdoctor wrote:
What surprised me though is that they even had this "//" trick working. This is actually a security hole that they should patch. This can lead to some nasty Denial of Service attacks if you have URL's that you can infinitely generate to bypass cache and still serve actual service content as a result instead of immediate 404's.


Can't you do this anyway (and as desired behavior) if you add a question mark with some random keystrokes to simulate new query string parameters? I do this with timecodes when I want to ensure users always get the freshest content. Adding an extra slash seems like it is doing the same thing.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Eli Gingerich
Canada
Kitchener
Ontario
flag msg tools
badge
Avatar
mbmbmbmbmb
6.5 hours.... this / or // or /// never worked for me.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Kristo Vaher
Estonia
Tallinn
Harjumaa
flag msg tools
badge
Avatar
mbmbmbmbmb
kbieb wrote:
Slashdoctor wrote:
What surprised me though is that they even had this "//" trick working. This is actually a security hole that they should patch. This can lead to some nasty Denial of Service attacks if you have URL's that you can infinitely generate to bypass cache and still serve actual service content as a result instead of immediate 404's.


Can't you do this anyway (and as desired behavior) if you add a question mark with some random keystrokes to simulate new query string parameters? I do this with timecodes when I want to ensure users always get the freshest content. Adding an extra slash seems like it is doing the same thing.


Correct, but this approach breaks the principle of 'always validate input and output'. Technically, if customer adds something new to URL string, even a GET variable named 'riot', you should detect this as it is technically not a correct input anymore.

Most websites don't check for it it, leading to loopholes like this. Then again, sometimes it's a feature, yesterday it did help some customers to bypass cache like this.

Timecodes is a nice example, but you should validate these timecodes as well. Thus in worst case scenario you get a DoS on X range of timecodes instead of near infinite amount of strings.

Overall you suppress a lot of risks by blocking everything except your 'known' input.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Brandon Mason
United States
Bend
Oregon
flag msg tools
mbmbmb
I think the takeaway from this is that board gamers will find a way to get their games. cool
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Tony Pecorelli
United States
flag msg tools
Avatar
mbmbmbmbmb
I did variations of //, ///, /////. These worked. ///////// Didn't.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Front Page | Welcome | Contact | Privacy Policy | Terms of Service | Advertise | Support BGG | Feeds RSS
Geekdo, BoardGameGeek, the Geekdo logo, and the BoardGameGeek logo are trademarks of BoardGameGeek, LLC.