Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About OrganicShamanic

  • Rank

Recent Profile Visitors

1,180 profile views
  1. That's correct. See's rate limiting is based on IP address (possibly amongst other things, but I've seen no evidence for anything else). Therefor, assuming each connection is making successful requests, more IP addresses allow you to make more requests per minute before you are limited/redirected.
  2. How many different sessions did you try this on? I did find I was getting timeouts on sessions without the X-Mapping cookie too, so there are definitely reasons for your request not to even reach the TrafficManager/Load Balancer. Do you have any network data from these attempts?
  3. You need to delete your cookies and try again. Keep deleting them and refreshing until you get through to the holding page. It might take quite a few attempts, but otherwise you're not even making successful requests for access
  4. 1) To get through to the registration page, you need to have the right cookies pointing to a specific server instance and allowing you past the holding page. 2) You then have access to the booking form, which when submitted sends your details to a server (probably the same server instance as the holding page you were previously requesting), which does some verification, and populates the response onto a new page (the confirmation page). 3) You then send all that confirmed information back to the server, and get a response which is nested into the payment information page. 4) You submit your payment details to a server (possibly the same as above, or possibly a special payment gateway), which verifies them and processes/queues the payment for processing, and responds with a confirmation or error. Unfortunately, even once past the holding page, it is possible for these servers to not be able to handle the amount of requests they are receiving. That causes time-outs and the information you are sending never reaches the server. There also appear to be some database errors coming back occasionally, when it gives erroneous responses. The reg page and payment pages are on separate screens because your registration details need to be verified before payment is attempted. That saves handling bad requests (e.g registration details which already have tickets allocated to them) when making payments.
  5. Yes. I'm afraid you were just unlucky to get allocated another cookie sending you to another bad server instance. There were alot of over-loaded servers timing out. Once you got a good one, you were making successful requests, and you would notice the difference!
  6. I'm afraid you were virtually doomed to fail, unless you could make a fresh request with no cookies and get allocated a functioning server. Essentially you need to either delete your cookies, or start a fresh session by using a different browser or restarting your browser with a new 'private' session (e.g incognito)
  7. No exactly: if you couldn't load the holding page it was probably because the server you had been allocated wasn't responding in time, probably because it was over-loaded. If the load on the server was reduced, then it would start to respond in time again. I think this does happen throughout the sale occasionally, so sometimes you go from having page timeouts to getting the holding page, but in my experience it's quite rare. Infact many of the bad servers continue to timeout until after all the tickets have sold out! So you probably have a close to 0% chance.
  8. Firstly, the tickets being held for 4 minutes I believe is just locking your registration details until you either complete the purchase or close the session. I haven't really checked this out though, so that is just a hunch. When you clicked confirm and nothing happens, something is timing out: Either your entire POST request has not been received, or it has but you have not received a response from the server. Either way it is probably because the server is handling more requests than it can reliably manage. In your case, it transpires that the POST request was received, and your card was billed, but no response was sent back from the server. I'm not sure exactly where the POST requests are directed (thats whenever you submit the form on each page reg details/confirmation/payment), but I wouldn't be surprised if the same server which holds you on the holding page handles the form submission. What I find interesting in your experience is that you were able to re-submit your registration details, despite having successfully bought tickets for them (you weren't aware of that at the time). It may be that there was a delay between processing your card and updating the database to show your registration details as allocated tickets. That might have something to do with why you didn't receive a response when the payment was successful. If anyone has any more network traffic data from the sale, I'd love to compare notes. I'm always a bit too pre-occupied securing my own to record it all.
  9. Because you have been allocated a cookie which directs you to a server operating within it's capacity. At this point all your requests were probably successfully responded to in less than 2 seconds, unless that server then gets allocated too many sessions, at which point it will also start timing out. That happened occasionally, but mostly once you had a good server, you were making successful requests. The sucker is, if you were unlucky enough to be allocated an over-loaded server, all your future requests would also be directed there. Hence never even seeing the holding page. A fresh request with no cookies would get a new server allocation. It appeared as though a lot of the servers were over-loaded, especially for the first 20 minutes. If you were not seeing the holding page, you weren't even making successful requests.
  10. There are many server instances, and alot of them were overloaded, so if you never saw the holding page, then whilst it is unlikely you got the same server everytime, you were still allocated an overloaded one.
  11. It depends what you consider fair. I think each request should be independent from the last, and offer you the same odds of success as every other request. This isn't the case if your first request determines whether or not you will be allocated a sever which defines the probability of success for each future request.
  12. The reason it becomes unfair is because once allocated an overloaded server, all of your future requests for the entire sale period will go to that same server. You may never even make a successful request.
  13. Regardless of discussions of a 'fairer' way to sell the tickets, there are technical issues with the current system which doesn't make it 'fair'. Particularly the page time outs. If you were getting page time outs instead of the holding page today, you were very unlikely to ever even get to the holding page. That's because you were always being directed to the same server instance, which was over-loaded. If you can't even connect to the holding page, you're not even making successful requests for access to the booking system. The number of over-loaded servers was huge, and I suspect something like only 1 in 10 requests were getting successful responses. Once a session was allocated a server operating within it's capacity, all requests were successful and responded to within 2 seconds, unless that server was incorrectly allocated too many requests by the load balancer, and which point you would be kicked off the holding page. On occasion this also happened at the booking system: leading to page time outs once a visitor had put their registration details in. I realise See Tickets are paid a small booking fee relative to the job, but I think they need to shore up some of these issues. Their load balancing is not working well, and it's creating a systemic disadvantage. If you were unlucky to be getting page time-outs to all your requests, you needed to wipe your cookies and make another request until you were allocated a functioning server. Otherwise your odds of success were very very slim. This partly explains why some are more likely to get through several times; if you get a good server, you're alot better off than many other people.
  14. I can no longer attend, so I won't be trying for myself, however I'll be helping others in the general sale on Sunday.
  • Create New...