June 2018

[gsp8181]

31 minutes ago, crazyfool1 said:

Hardly understood a word of it ... but thats some first post  

Haha yeah it's a bit complex but I hope someone can make a bit of sense out of it to understand how all the tickets machinery goes on. I think it's a good trade off on the fair side. It's designed in a way to reduce load on the server so people won't moan 'it just gives me an error every time I log onto the page' and lets people actually see the queue so they know they are in with a shot. It's pure luck. Every time there is some fault on seetickets end there is a massive twitter storm, 'i didn't get through the queue' isn't the same headline

I personally think if they moved towards a ballot people would just register multiple times using everyone's address they know and with lots of different photos and stuff the ballot. i.e. register at your mums, dads, grandmas, student house, office. Tons of tickets would get cancelled when they try and mop up the damage including having a doppelganger on the other side of the country. It could also fall afoul of the Gambling Act (I have no idea this is just a guess). England vs Croatia in Hyde Park ran on a ballot and that just had people entering as many times as they could

Edited August 9, 2018 by gsp8181

[Walker2295]

On ‎7‎/‎27‎/‎2018 at 9:38 AM, Quark said:

You remember correctly, 6 per person. This is why I actively try to discourage more people form coming unless they fit into a block of 6 

I got nervous as our group went up to 7 for a bit and trying to figure out our options to try and get everyone. Unfortunately (deep down very thankful ) that someone has pulled out for other commitments and back down to that max of 6  

[eFestivals]

41 minutes ago, gsp8181 said:

Haha yeah it's a bit complex but I hope someone can make a bit of sense out of it to understand how all the tickets machinery goes on.

thanks for all that.

Just about made sense to me - and it's just about as I'd presumed it was. 

[Quark]

1 hour ago, crazyfool1 said:

Hardly understood a word of it ... but thats some first post  

@gsp8181 out

[lintonkak]

I'm showing this thread to the developers at my work as they'll understand it. Other than that I'm cleaning toilets next year if I have to as I'm not having another 2017 experience watching it on TV and knowing exactly what I'm missing. Good luck everyone! 

[Heather90]

On 7/14/2018 at 11:18 PM, Tyonks said:

I know this is hugely off topic, but I went to Memphis and Nashville as part of of my honeymoon. Loved both. Did you take a trip down to New Orleans too? 

Massively late reply but yes we did. Found a great bar called Bourbon Heat at bottom of Bourbon st. However, I was disappointed overall. Full of kids getting wasted, not much else to do and racism. 

I don't think I've ever seen real racism until I went there. I was horrified by the behaviour of white kids wearing Jesus loves me T-shirts. 

Memphis was way more integrated and just an awesome place. The lady jazz singer in Silky O'Sullivans was incredible. Also saw a Bluegrass singer in the afternoon that promised a beer to anyone who knew any song he sung. Me and my friend just sat there entranced. Magical place, can't wait to get back out there

[Pinhead]

On 8/9/2018 at 10:33 AM, gsp8181 said:

There is a routing table either at an intermediate router or on a load balancer. That got overloaded one year and as such all connections were dropped originating from new IPs probably because the program that was managing adding iptables rules was too overloaded to cope. Entirely the same principle that using bittorrent with 100+ connections knackers old routers. Mobile connections work better because they are behind a NAT and multiple people share a single IP. Therefore the chances are somebody else has already connected from that mobile network which has an existing routing rule in place are pretty high.

From personal experience with scaling cloud systems they are NOT operating a queue (defined as first in first out), it would be incredibly computationally intensive given that the hardware is only used 4 days a year. They also love to brag about how fast tickets sell out. I have had multiple devices open that have entered the queue in order and have been placed on the ticket screen in a completely different order that the site was accessed. They also will not rate limit by IP only given that a lot of people use corporate/uni/mobile networks share external IPs (they filter by the X-Mapping-???????? cookie which is shared per browser). A uni would have hundreds of hits per second even if none really press F5, vs a bloke with 5 browsers open refreshing like mad on his own IP. If they operated a queue it would mean that if you did not enter the site at the time that the tickets come on sale, you would have no chance, and i've had evidence to the opposite. Tickets would sell in a more logarithmic way resulting in a slow sell out but this is a bit complex to explain on a forum post .

They instead operate a token system. They have 3 main load balancers split via DNS which has a number of holding machines and ticket buying machines. For instance there could be 10000 tokens, each time you refresh it would see if a token is available and route you over to the ticket buying machine, if there wasn't then it would keep you on the holding machine. Once you've bought your ticket, the token would be released. If you refresh though on the page immediately after getting onto the ticket buying page it would boot you out again to discourage auto refreshers. This would boot you out for all tabs in the same browser as it does it by X-Mapping, i.e. if you get through and another tab gets through and autorefreshes, it would kick both instances out.

There are a number of different load balancers and routing in place and i'm actually impressed by it's resilience given the immense amount of traffic it must see compared to other shoddy jobs I regularly use

Tl;dr it's pure luck whether you press F5 the moment a space frees up, there is no ip filtering in place because it would disqualify a large chunk of the population such as uni students and people at work

This makes sense and broadly supports previous years analysis and 'leaked' information about the session management / load balancing arrangement that See use, at least for the last ticket sale anyway (who knows, they may presumably review and refine it each year). Interestingly though, you suggest mobile users may have a better chance due to the reuse of IP's along their telcos public range that clients are NAT'ed to? Would that not be the same for some other networks though - some ISP's cycle their clients home broadband public IP's routinely and at work we certainly do that to obscure public services a bit more to potential external 'listeners'. One suggestion one year was also that See used a reputation filter at the very front end to prevent DoS which lead to the suggestion that hitting the site before the sale a few times might be beneficial so that your IP could be checked against a reputation database (depending on what solution is being used). Any thoughts?

[gsp8181]

21 hours ago, Pinhead said:

This makes sense and broadly supports previous years analysis and 'leaked' information about the session management / load balancing arrangement that See use, at least for the last ticket sale anyway (who knows, they may presumably review and refine it each year). Interestingly though, you suggest mobile users may have a better chance due to the reuse of IP's along their telcos public range that clients are NAT'ed to? Would that not be the same for some other networks though - some ISP's cycle their clients home broadband public IP's routinely and at work we certainly do that to obscure public services a bit more to potential external 'listeners'. One suggestion one year was also that See used a reputation filter at the very front end to prevent DoS which lead to the suggestion that hitting the site before the sale a few times might be beneficial so that your IP could be checked against a reputation database (depending on what solution is being used). Any thoughts?

Yeah they do tweak it every year. I believe that mobile users have a better chance if there are issues on the routing table so it's always worth having it as a backup. Mobile Data networks are double NATed, you would have a NAT at the tower and another NAT further inside the network, a hell of a lot of phones would have the same IP. Therefore if it was rate limited, your phone would be the worst possible device to try and get tickets on. Normal consumer grade broadband has the 1 ip per router for a few devices

Reputation filters could be acquired through 3 main means, they could be hard coded and be checked against for every request (best way), they could be checked each time and probably cached (which is how email works) or they could be offsourced to someone like cloudflare (easiest way).

Cloudflare isn't used because a dig query would unearth that one, plus you'd get a CAPTCHA from accessing with AWS EC2.

I'm guessing a API based filter isn't active as well as the only providers I can find check for viruses, email spam and hacking threat sources and aren't appropriate for this use case

This leaves the hard filter, either for prioritising good traffic (such as bypassing IP rate limiting through carrier NAT) or limiting bad traffic (people using creative solutions to get tickets eg EC2 or autorefreshing). Both these solutions don't seem to be in place as if you spawn an ec2 instance which should be the worst of the worst in reputation filtering and repeatedly shows up on blacklists, vs using chrome on your iPhone in Central London which should be the best. Try refreshing glastonbury.seetickets.com 60 times in 60 seconds and both will hit the session rate limit at the exact same time. Ofc there is the chance that this is all a red herring and it uses a different system of filtering come October

I don't think it's a reputation filter I just think there was an error with the setup when everyone had connection errors, either bursting the instances didn't work and people were redirected to overloaded instances, or the glastonbury.seetickets.com NAT/load balancer failed and couldn't cope with any more entries therefore people who had already connected to a successful instance would have had a better chance. When I was in Germany, me and my neighbour had 1&1 DSL, I got on and she didn't despite both being in the same city with the same unknown ISP (in UK terms)

[stuartbert two hats]

27 minutes ago, gsp8181 said:

Yeah they do tweak it every year. I believe that mobile users have a better chance if there are issues on the routing table so it's always worth having it as a backup. Mobile Data networks are double NATed, you would have a NAT at the tower and another NAT further inside the network, a hell of a lot of phones would have the same IP. Therefore if it was rate limited, your phone would be the worst possible device to try and get tickets on. Normal consumer grade broadband has the 1 ip per router for a few devices

Reputation filters could be acquired through 3 main means, they could be hard coded and be checked against for every request (best way), they could be checked each time and probably cached (which is how email works) or they could be offsourced to someone like cloudflare (easiest way).

Cloudflare isn't used because a dig query would unearth that one, plus you'd get a CAPTCHA from accessing with AWS EC2.

I'm guessing a API based filter isn't active as well as the only providers I can find check for viruses, email spam and hacking threat sources and aren't appropriate for this use case

This leaves the hard filter, either for prioritising good traffic (such as bypassing IP rate limiting through carrier NAT) or limiting bad traffic (people using creative solutions to get tickets eg EC2 or autorefreshing). Both these solutions don't seem to be in place as if you spawn an ec2 instance which should be the worst of the worst in reputation filtering and repeatedly shows up on blacklists, vs using chrome on your iPhone in Central London which should be the best. Try refreshing glastonbury.seetickets.com 60 times in 60 seconds and both will hit the session rate limit at the exact same time. Ofc there is the chance that this is all a red herring and it uses a different system of filtering come October

I don't think it's a reputation filter I just think there was an error with the setup when everyone had connection errors, either bursting the instances didn't work and people were redirected to overloaded instances, or the glastonbury.seetickets.com NAT/load balancer failed and couldn't cope with any more entries therefore people who had already connected to a successful instance would have had a better chance. When I was in Germany, me and my neighbour had 1&1 DSL, I got on and she didn't despite both being in the same city with the same unknown ISP (in UK terms)

You're my new favourite poster.  Or favourite new poster.  Either - both actually.

[JoeyT]

1 hour ago, gsp8181 said:

Yeah they do tweak it every year. I believe that mobile users have a better chance if there are issues on the routing table so it's always worth having it as a backup. Mobile Data networks are double NATed, you would have a NAT at the tower and another NAT further inside the network, a hell of a lot of phones would have the same IP. Therefore if it was rate limited, your phone would be the worst possible device to try and get tickets on. Normal consumer grade broadband has the 1 ip per router for a few devices

Reputation filters could be acquired through 3 main means, they could be hard coded and be checked against for every request (best way), they could be checked each time and probably cached (which is how email works) or they could be offsourced to someone like cloudflare (easiest way).

Cloudflare isn't used because a dig query would unearth that one, plus you'd get a CAPTCHA from accessing with AWS EC2.

I'm guessing a API based filter isn't active as well as the only providers I can find check for viruses, email spam and hacking threat sources and aren't appropriate for this use case

This leaves the hard filter, either for prioritising good traffic (such as bypassing IP rate limiting through carrier NAT) or limiting bad traffic (people using creative solutions to get tickets eg EC2 or autorefreshing). Both these solutions don't seem to be in place as if you spawn an ec2 instance which should be the worst of the worst in reputation filtering and repeatedly shows up on blacklists, vs using chrome on your iPhone in Central London which should be the best. Try refreshing glastonbury.seetickets.com 60 times in 60 seconds and both will hit the session rate limit at the exact same time. Ofc there is the chance that this is all a red herring and it uses a different system of filtering come October

I don't think it's a reputation filter I just think there was an error with the setup when everyone had connection errors, either bursting the instances didn't work and people were redirected to overloaded instances, or the glastonbury.seetickets.com NAT/load balancer failed and couldn't cope with any more entries therefore people who had already connected to a successful instance would have had a better chance. When I was in Germany, me and my neighbour had 1&1 DSL, I got on and she didn't despite both being in the same city with the same unknown ISP (in UK terms)

Can someone translate?

May as well be typing in Chinese  

[Crazyfool01]

17 minutes ago, JoeyT said:

Can someone translate?

May as well be typing in Chinese  

對我也沒有意義

[gsp8181]

23 minutes ago, JoeyT said:

Can someone translate?

May as well be typing in Chinese  

Each person has roughly an equal chance of getting tickets and there isn't any benefit or disadvantage to any specific group of people, like people suspecting that people in cities have an easier time, or people in Somerset. One year it was accidentally made better to be trying for tickets through your phone, two other years by accident it was made easier if you were reading the forums to get a specific trick to get on to the booking page. They try and tweak it every year but there isn't a consistent magic way to get tickets other than getting all your pals to try with you 

Edited August 14, 2018 by gsp8181

[Pear_Cider]

2 hours ago, crazyfool1 said:

對我也沒有意義

Me neither, but I still enjoyed reading it!

[Pinhead]

That's interesting about EC2 as someone I know who hosts their corporate SAP environment there was suggesting that they might try hopping off that this year to gain a perceived advantage.

On the subject of NAT though - I would have thought that this was broadly being abandoned now with IPv6 adoption, though I can see continued advantages to security systems by using it.

Increasingly I would expect to experience See making increased use of the API and SaaS offerings in the cloud for providing these services rather then cook their own solution on there.