Get those festival tickets

Have you ever gone to a live music or sporting event website to purchase tickets on the day they are released, only to find the website falls over every time you try to make a purchase, if you can access it at all?

It becomes impossible to browse the site, let alone acquire those coveted tickets, because the site has been overloaded by thousands of visitors. There is, however, an apparently legitimate way to get your tickets.

Once you've navigated to the event website, say www.bigevent.com, your transaction is usually handed to another public web server to select the ticket dates and take your personal/payment details.

The payment web server is typically at another url, and is far less heavily loaded because no-one goes to it directly. Because everyone is trying to access the event website, it falls over, so no-one ever gets to the payment server.

The obvious trick is to go straight to the payment web server. But how?

The answer depends on who is handling the ticketing, and how they have configured their payment engine, so you'll need to do a little research prior to the event.

Ticketing payment engines are often brought online a few minutes before the event website goes live. In many cases, each event is given a URI, such as www.ticketingsite.com/event_id=50. Each 'event_ID' relates to a specific event, usually allocated sequentially. Try working through a few numbers to see which event each URI relates to - id 49 might be a Robbie Williams concert, id 48 might be a test match.

So try to find out which ticketing business is handling ticketing for the event (Google!) and have a look at some of the other events that they're handling ticketing for.

Then find the most recent event ID, and it's likely that the next ID in sequence will be the hot gig that you're looking for. Navigate direct to that URI the moment the event goes live, and bang, you've got your tickets.

Alternatively, the payment engine website may use load balancing. In the case of an Arctic Monkeys gig two years ago, the load balanced servers had the names www, www2, www3 etc. It turned out that www8 was hardly being used, so we navigated to it direct and got the tickets.

Another example, this time of Glastonbury 2007: once one had got to the ticketing page (which took some doing!), the ticket purchase process had an interesting issue that allowed multiple tickets to be purchased: it failed to expire the browser session after one had completed the purchase of tickets, so one could simply hit 'back' through the payment process, and buy more tickets.

There's no single solution for every ticketing website, but do a little research beforehand, find out who the event organiser is using to handle ticketing, and you'll dramatically improve your chances.

For popular events, there will always be more registrations than tickets. Bypassing the initial event web page is the key, because this is the point at which the servers struggle to cope.

Coding the website and its applications using Ajax may be a solution to the overloading issue. The problem is caused by thousands of visitors to the site constantly hitting 'refresh', creating a denial of service attack, affectionately known as 'the refresh of death'.

If the page can be made to appear to be working (however slowly) then the refresh request from the user is less likely. Among several useful functions, Ajax can be used to facilitate refreshing only part of the page, therefore reducing load on the web server.

It also wouldn't be hard to set up a simple queuing system for online purchasers but sadly there is little incentive for the ticket agencies to do this. They know they will make the sales irrespective of whether one person tries to access the payment engine per minute or a thousand, so there's no real need to install a more resilient system.

- Ken Munro is managing director of SecureTest. He can be contacted at ken.munro@securetest.com.

festivalgetsecuritythosetickets