Let's play master and servant

[venta]

Yesterday was the annual F5-fest of Glastonbury tickets going on sale. Which was made considerably more protracted because Seetickets were having "technical issues" for the first 30 minutes of the sale period.

I was also watching #glastonbury on the twitters. Lots of people berated Seetickets for their poor timing in having "technical issues" the day Glasto tickets go on sale. Er, y'know? I don't think it's coincidental. I think we, the Glastonbury punters, pretty much are the technical issues.

From the numbers I've seen, there were a million people registered to buy 135,000 tickets. That means a lot of disappointed people. And that's not Seetickets' fault. Once the issues were resolved, Seetickets were churning through 3000 ticket sales a minute on servers that were being hit by many times more people than that. Servers really aren't my specialist area, but I'm pretty sure that's not a trivial problem to solve. Compared to a decade ago, the ticket sales are incredibly smoothly handled.

However! One thing did baffle me. ChrisC and I sat on the sofa with three laptops between us, all hooked to the same wi-fi signal. His two laptops fairly consistently loaded the holding page which auto-reloaded itself and (eventually) popped you through to the actual payment page. My laptop consistently failed with the "connection to server was reset" message.

For an hour.

At one point I had two browser tabs open, and they both simultaneously loaded the holding page. They both auto-refreshed after ten seconds, and returned to the "connection reset" error. That was the only time I saw an actual page load on my machine.

Needless to say, ChrisC bought the tickets. I'm just confused as to how it's possible. Some sort of glitch in the server load-balancing software? Does it send (say) machines with differing IP addresses through different routes? I remember an incident at my old workplace where someone was trying to access a server whose load-balancing algorithm routed machines based on IP address parity (and the server handling "even" addresses was down). But I assume Seetickets are a bit more clueful than that.

Comments

[bibliogirl.livejournal.com]

If you were both hooked to the same wifi then the chances are that -- as far as Seetickets were concerned -- you will have been coming from the same IP address.

We had, between us and my sister, ten different browsers (not browser windows -- different types of browser on same machine) across four machines and three IP addresses (two different ISPs). None of us saw a sniff of a payment page from first until last. :(

[bateleur.livejournal.com]

If you were both hooked to the same wifi then the chances are that -- as far as Seetickets were concerned -- you will have been coming from the same IP address.

If that's the case then how do things like UDP punching through NAT firewalls work?

[bibliogirl.livejournal.com]

"it depends", and is generally handled by the firewall itself in my (limited) experience of same. But web servers will generally be looking only at the outside IP address and won't see any of the stuff going on with NAT. To take an example with which I am most familiar, if rotwang and I both access an external website from different machines on our local network, what gets logged in both cases is the IP address of our router, and not any of the information relating to the make-up _of_ the local network (e.g. our local IP addresses). The server at the other end would be able to tell the difference between the two machines via cookies, session IDs, probably browser types -- but not just by inspecting the IPs.

[bateleur.livejournal.com]

Ah, interesting.

And awkward. :-)

[bibliogirl.livejournal.com]

;)

All bets are of course off if you're coming from a non-NATted (or only partially NATted) network, but most residential customers will only have the one external IP. We have two but only because we've got a backup ISP -- I had my phone on that connection and didn't see even a holding page :(

There have certainly been suggestions that some ISPs were having more trouble than others yesterday, and that some of the problems may have been DNS-related (and therefore, yeah, possibly involving caching to servers which weren't reachable)

[pm215]

It's complicated, but the whole reason for the complication is exactly because every machine behind a NAT gateway appears to the outside world to have the IP address of that NAT gateway. The gateway can generally do rewriting of port numbers as packets pass through (and obviously must do IP address rewriting), and that's how it allows multiple client machines to work simultaneously.

[bateleur.livejournal.com]

Well yes, but I had previously assumed that the outgoing packets' additional information which said where the replies should go must effectively be a NAT-specific machine address and therefore act in an address-like way to specify an individual machine from the point of view of the server even if not via an IP per-se.

[pm215]

If the source address on the outgoing packet is anything other than the NAT gateway's own IP address, it won't ever see the replies. (I guess you could have a NAT setup where the gateway has multiple external IP addresses that it will get packets for, but typically the reason you're using NAT is because your ISP is only giving you one IP address...)

[venta.livejournal.com]

We only had two different browsers going on here :) Both of us failed to load anything at all, ever, using IE (and it turns out IE's error reporting is a bit rubbish). My reset-connections and ChrisC's succesful loading were both Firefox. Oh, and ChrisC also got the holding page loading on Safari, or whatever the cool iOS kids have on their phones these days.

[bibliogirl.livejournal.com]

I actually think Safari's error reporting (on a PC) was even worse than IE's. (Compared with Firefox, Chrome and Opera...)

I never got to find out what the error page would have looked like on an iPhone ;) All I got there was "could not connect".

[bateleur.livejournal.com]

I don't know what the standard approaches are, but it occurs to me that possibly the server a given client is served by gets cached somewhere so that once you've been assigned one then anything you do will continue to involve the same one. It probably doesn't matter for SeeTickets, but for some applications that could be quite efficient.

[lanfykins.livejournal.com]

Has anyone claimed the Depeche Mode kudo yet?

[venta.livejournal.com]

Yes, you :)

[waistcoatmark.livejournal.com]

Why on earth don't they have an olympics-style lottery? It assume there's good reasons why they don't just have an auction, but an official lottery would just formalise what's actually happening...

[venta.livejournal.com]

I have occasionally wondered if they will switch to a lottery.

I don't think it'd quite formalise what's happening (though obviously there's a big lottery element to the way they're sold at the moment). I think lots of people register with vague interest, but then don't go on to try and buy tickets. A colleague of mine intended to buy tickets, but forgot they were going on sale. At present, I think the tickets are bough by those who are keen enough to get up and spend an hour faffing about on a Sunday morning fighting with the website - so the tickets go to the keenest[*]. Which is an interesting idea. I'm not sure it is a good idea.

(I'm not sure if Olympics tickets were resellable, so if you got tickets you then decided not to use you could sell them on. You can't with Glastonbury tickets.)

[*] In general. Obviously there will be cases where mad Glasto nuts were unable to get to a PC, or are very keen but highly disorganised, etc.

[waistcoatmark.livejournal.com]

I believe that Olympics tickets could only be sold back to the organisers to stop touting. But as I ignored the whole thing as much as possible (except for a couple of events with a family friend competing), I could be wrong.

They certainly had the same "we want the most passionate, not the most rich. Except for all the corporate entertainment stuff: that's different" thing going on that Glastonbury goes for.

[satyrica.livejournal.com]

glad you were successful too; see you there!

[venta.livejournal.com]

Excellent :)