I’m told it’s cellular polling. ie, each terminal has a cell modem in it, which it talks back to the main server(s) with. Every so often (3 mins or so), the server asks every dock how many bikes/docks/spaces etc it has. I think the docks can also query back to ask for what near ones have.
Personally, I’d do it the other way:
* docks call back when something has changed, at most every 30 seconds
* central system calls into the docks every so often (eg 10 mins), esp if it’s not heard from the dock for 10 mins.
This would mean a lot less traffic – most docks would go 10-15 mins without a substantial change. Even in high use situations, it could be set to only call in every 30 seconds (which might be 5 changes in one hit) – which would be more up to date, but less overall traffic.
GPRS (which is the same as 3G, only a LOT slower – 56k or so vrs 1.5meg – if you have an iPhone, when it changes to the (.) thats GPRS – you have (.), E (EDGE – Enhanced GPRS) and 3G) is packet switched, so while in theory you could open a TCP connection to the server and leave it open, it’s not worth it – just bring it up and down as needed. The overhead is minimal. I doubt Serco/TFL is paying much for the data – it’s a small amount (at a guess, less than 5GB/month for all 400 docks – peanuts in the grand scheme of things), so it’s mostly the cost of 400 sim’s/numbers, which would be cheap at volume….
I believe (from memory, not 100% sure), the data goes like this:
* serco server polls the nodes (takes a while – 1-2 mins all up. I can has threading?)
* serco server collates the data and stores it in it’s database
* serco server pushes the data in XML format to the Azure server (where we all get it from) and TFL (no idea on the format), which is used for the map, customer service and all that.
* wait until the end of the 3 minutes from when you started it all, and do it all again.
I assume Serco got slapped for doing more than just having out of date maps. More the large over-charging of customers, bikes not available, that kinda thing.