geeky techie chat about the ticket sale

[UEF]

I'm slightly disappointed that many of the people I've always viewed, based their usernames and avatars, to be wild eyed loners at the gates of oblivion on the last freedom moped out of nowhere city are actually IT types with a penchant for discussing IP addresses.

I think we'd still take up the offer on that moped.

I've met very few legit, full time, live in the caravan hippies at Glasto. Mostly up towards the healing fields obviously. Got in a conversation with a group of them once who had no knowledge of the ticket buying process or the fact you had to preregister, they just got given tickets they said. Clearly operating under a completely different universe.

[parsonjack]

I'm slightly disappointed that many of the people I've always viewed, based their usernames and avatars, to be wild eyed loners at the gates of oblivion on the last freedom moped out of nowhere city are actually IT types with a penchant for discussing IP addresses.

Given what it takes to get a ticket I'd guess the festival is full of them these days.

[iwalker]

In what way is it an advantage having 6 on the form instead of 4 ?

If anything it would be a disdvantage. It takes more time to input the details of 6 than say 2 meaning a delay in getting to final payment, as there is no 'lock' on tickets then the faster you get to payment the better chance you have of securing tickets.

On top of that there is a greater chance of error - someone giving you the wrong reg number etc.

If it is to do with more people trying then that still would be the same regardless of how many you can put on one form.

Personally I think you should be able to book up to say 20 on one form. Only getting tickets for half your group is pretty shitty. (but obviously better than getting none if your one of the lucky ones).

Ok then, have no upper limit once 80% of tickets are sold.

Then the more details you enter, the more the clock ticks and the more chance of it being sold out and no one gets to go.

Feeling lucky? :-)

[Woffy]

Unresponsive backend servers should be spotted by the load-balancer where a 'keep-alive' is configured to poll the back end routinely in a number of ways, the simplest being a ping. For a web service its more efficient to configure a L7 keep-alive that actually asks for an HTTP200 response to a URL.

If the keep-alive fails after a predetermined amount of retrys the LB drops it from the server-farm and doesn't send any more connection requests to it until the keep-alive determines it's alive again.

the sticky session is there to ensure that a user connection is maintained throughout the transaction to the same server...where there are multiple servers in the farm....it is usually L3 source IP and cookie based. If the server goes down during the session all connections to that server are dropped by the LB and the sticky table for them is cleared out,...forcing customers to another server when they reconnect for a new session. in badly designed systems the sticky is maintained and clients continue trying to get to the dead server either until the sticky table is manually cleaned by an admin, or the sticky session cookie times out, the timeout being determined by the admin..

well designed systems will use a public IP which is routed to the LB...and then NAT'd to private IP's within the LB configuration for the backend server-farm.

I have never felt so old AND thick at the same time.

[midnight]

Heehee, same here. Just The first paragraph of that quoted post was enough to make me feel like that. A bit like reading Mandarin, transferred into latin script but without a dictionary.

I'm grateful there's people out there doing & understanding these things, though, so that I don't have to.

[TomViolence]

I'm far from a techie so I'm not really sure what this means but I've been following a few variations of last year's ticket pages and just received this response

"There was a status change in http://glastonbury.seetickets.com/event/glastonbury-2016-ticket-coach-travel-deposits/worthy-farm-pilton-somerset/850005.

The HTTP response is: 200 OK .

The previous HTTP code was: 404."

[carlosj]

I'm far from a techie so I'm not really sure what this means but I've been following a few variations of last year's ticket pages and just received this response

"There was a status change in http://glastonbury.seetickets.com/event/glastonbury-2016-ticket-coach-travel-deposits/worthy-farm-pilton-somerset/850005.

The HTTP response is: 200 OK .

The previous HTTP code was: 404."

 

Your monitoring software is just notifying you that the page you're watching has changed from 'not available' to available (this link is redirected to the photo registration page, instead of the ticket sale page) here the page to register you and your photo). Something like this would appear when the ticket page opens next Sunday or for future sales.

Edited September 22, 2015 by carlosj

[Sawdusty surfer]

 

I think we'd still take up the offer on that moped.

 

I've met very few legit, full time, live in the caravan hippies at Glasto. Mostly up towards the healing fields obviously. Got in a conversation with a group of them once who had no knowledge of the ticket buying process or the fact you had to preregister, they just got given tickets they said. Clearly operating under a completely different universe.

 

You'd be amazed at how many there still are.  

[Kellg80]

So confused

[TomViolence]

Your monitoring software is just notifying you that the page you're watching has changed from 'not available' to available (this link is redirected to the photo registration page, instead of the ticket sale page) here the page to register you and your photo). Something like this would appear when the ticket page opens next Sunday or for future sales.

Thanks! No ground breaking discoveries here then :'(

[___S_o_m_a__]

You'd be amazed at how many there still are.  

Good and long may it continue :-)

[Room to sway]

So confused

 

I'll try and explain with a (much slower) real-world example.

 

Visiting a website is exactly like a physical letter exchange; you send a letter to Glastonbury, the network ensures they receive it, they read the letter to understand what you want, pop a copy of a page in an envelope, and send it back to you. This happens for every click. (Technically a single page is many letters back and forth, but that's not important for this example.)

 

Imagine that hundreds of thousands of letters are dumped at the front door of the farm. (These are from all the people wanting a ticket.)

 

The load balancer is like a guy at the door, who knows people inside are REALLY busy and has been told to randomly decide whether your first letter should get through the door or not. Once someone inside gets your letter, they tell the gatekeeper to let all letters from you through again. If the people inside are too busy (i.e. the servers are all too busy) then your letter just gets left in the field and is turned into mulch, along with your dream of buying a ticket.

 

The "sticky session" parsonjack mentioned is just the method by which Glastonbury are able to remember that you've got through once, and so should be allowed through again. Like having a ticket at the festival itself, really. "I've got a ticket, you know who I am, let me in".

 

Without a session, you're just a random shmuck, as far as Glastonbury is concerned, and so your fate is left with the guy at the front door.

 

 

I really hope that makes sense Just reply back if not, or if you want any extra details.

[stuartbert two hats]

I'll try and explain with a (much slower) real-world example.

 

Visiting a website is exactly like a physical letter exchange; you send a letter to Glastonbury, the network ensures they receive it, they read the letter to understand what you want, pop a copy of a page in an envelope, and send it back to you. This happens for every click. (Technically a single page is many letters back and forth, but that's not important for this example.)

 

Imagine that hundreds of thousands of letters are dumped at the front door of the farm. (These are from all the people wanting a ticket.)

 

The load balancer is like a guy at the door, who knows people inside are REALLY busy and has been told to randomly decide whether your first letter should get through the door or not. Once someone inside gets your letter, they tell the gatekeeper to let all letters from you through again. If the people inside are too busy (i.e. the servers are all too busy) then your letter just gets left in the field and is turned into mulch, along with your dream of buying a ticket.

 

The "sticky session" parsonjack mentioned is just the method by which Glastonbury are able to remember that you've got through once, and so should be allowed through again. Like having a ticket at the festival itself, really. "I've got a ticket, you know who I am, let me in".

 

Without a session, you're just a random shmuck, as far as Glastonbury is concerned, and so your fate is left with the guy at the front door.

 

 

I really hope that makes sense Just reply back if not, or if you want any extra details.

Sounds more like a 503 (people are too busy) or 403 (no ticket!)

 

Now a 404 is more like if the letter turns up, but the building has gone!

[Room to sway]

Sounds more like a 503 (people are too busy) or 403 (no ticket!)

 

Now a 404 is more like if the letter turns up, but the building has gone!

 

Well no - if the building's gone you wouldn't get any response code

 

(Sorry, LITERAL POLICE ALERT)

[stuartbert two hats]

Well no - if the building's gone you wouldn't get any response code

 

(Sorry, LITERAL POLICE ALERT)

Fair point, this is the geeky thread!

 

Ok, it's more like the address includes a flat number, but that flat isn't in the building.  Better?

[Room to sway]

Better

[big__phil]

Fair point, this is the geeky thread!

 

Ok, it's more like the address includes a flat number, but that flat isn't in the building.  Better?

 

WHAT?!? So Worthy Farm is made of flats now?!

 

So confused....

[stuartbert two hats]

WHAT?!? So Worthy Farm is made of flats now?!

 

So confused....

No, but seetickets.com is a building and glastonbury.seetickets.com is like a wing of that bulding and 

http://glastonbury.seetickets.com/content/extras

 is a room in that building.  Make sense?  Thought not.  I'm a bit lost now and I make a living from this sort of thing!  It's like an explanation from I'm Sorry I Havn't a Clue, appropriately enough.

Edited September 23, 2015 by stuartbert two hats

[Pinhead]

There's also an IP 'reputation filter' in front of the load balancer....

[stuartbert two hats]

There's also an IP 'reputation filter' in front of the load balancer....

Come on, give us a metaphor.

[Kellg80]

I get what you mean now. Just have no idea how to use the info lol.

[incident]

Come on, give us a metaphor.

A bouncer with a list of known ASBOs.

[Pinhead]

The whole technical set up See had for ticket sales was discussed at great technical length a few years ago on here iirc, with at that time at least the design being IP filter => load balancer (actually quite a sophisticated one that managed session pools as well) => IIS 7 => SQL Server back end. The whole lot was on a Virgin cloud business package of some sort.

 

Probably all changed a bit again since. Knowing a bit of how it worked was of little known demonstrable advantage on the day however.

[stuartbert two hats]

The whole technical set up See had for ticket sales was discussed at great technical length a few years ago on here iirc, with at that time at least the design being IP filter => load balancer (actually quite a sophisticated one that managed session pools as well) => IIS 7 => SQL Server back end. The whole lot was on a Virgin cloud business package of some sort.

 

Probably all changed a bit again since. Knowing a bit of how it worked was of little known demonstrable advantage on the day however.

It fascinates the shit out of me, especially as a .net dev.

[big__phil]

The whole technical set up See had for ticket sales was discussed at great technical length a few years ago on here iirc, with at that time at least the design being IP filter => load balancer (actually quite a sophisticated one that managed session pools as well) => IIS 7 => SQL Server back end. The whole lot was on a Virgin cloud business package of some sort.

 

Probably all changed a bit again since. Knowing a bit of how it worked was of little known demonstrable advantage on the day however.

 

 

jargon¹/ˈdʒɑːɡ(ə)n/

 

noun

1. special words or expressions used by a profession or group that are difficult for others to understand.