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

[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...)