3 ms·
From the published details I've been trying to work out the architecture. The 'server' piece seems to be based around an XML message store (hey it was the 90s
by codeulike 3y ago
From the published details I've been trying to work out the architecture.
The 'server' piece seems to be based around an XML message store (hey it was the 90s dont forget, XML was the big new thing) called Riposte build by Escher Group.
There were some touchscreen EPOSS terminals for the post offices - these may also have been part of the Riposte system. Then there was a bunch of other stuff built around that and written in VB6 (which for the time was a reasonable choice unless you wanted to go Java or C++) running on NT workstations.
Syncronisations from the thousands of post offices to the central server seemed to be via scheduled programs that picked up local message files (probably xml) and sent them to the central server over ISDN lines.
Centrally there was something called the 'cash account' which pulled in those messages and (I guess?) added them to the riposte xml message database. As mentioned in the witness statements, they had no agreed data dictionary or schema for all the XML stuff so no centrally agreed scheme of how to represent all the different messages. So somewhere something was probably written to 'transalte' all these different messages into some nominally agreed standard.
- tauchunfall 3y ago>added them to the riposte xml message database I've watched some parts of [1] on youtube, and it seems the riposte system is on the machines in the post office. if it is also used in headquarters, I don't know. they have messages that have incremental sequence numbers to identify the replicates messages. messages are put into the message store where each message has a checksum. when a message is read and gives a CRC error, someone raises a call, and they rebuild the message store. which recalculates the checksums, I assume. CRC errors can be caused by data corruption on the counters. so this implies data is stored on the counters. when they rebuild the message store it seems they can use data from the other counter which hopefully has no corrupted message (but the former software engineers can't quite remember if this was true, at least she says so). so it seems they have redundancy between these counters. when CRC erros happen often, they'll replace the counter. I also assume they describe the Horizon system pre-2010. [1] "Anne Chambers - Day 67 AM (26 September 2023) - Post Office Horizon IT Inquiry", https://www.youtube.com/watch?v=q72zvd9Iz3Q https://www.youtube.com/watch?v=q72zvd9Iz3Q
- codeulike 3y agoThats interesting thanks. re: Riposte: I found some old pages about it on the wayback machine https://web.archive.org/web/20000706232447/http://www.eschergroup.com/index-prod.html https://web.archive.org/web/20000706232447/http://www.escher... "Any fear of complete local failure is alleviated by the fact that each workstation can recover from a central location." And also, er ... "Riposte protects against fraud by providing a clear and complete audit trail for every transaction."
- tauchunfall 3y agoReading the Riposte page from your Wayback Machine link it seems Eschergroup gave Fujitsu UK the hardware concept with redundant workstations, and Fujitsu extended it for the data integrity concept of their application [1] ("2 Horizon Data Integrity", page 6). The concept looks really nice on paper, also the network communication considerations [2]. But there were bugs in Horizon like when a notebook at a post office was shutdown before a certain time, there were no day-end-markers added to the last transaction, and it seems they had no concept to let the system check this on the next day. There were bugs where the start times for transactions where missing, and these transactions were filtered in certain views however these messages eventually were transmitted. [1] FUJ00080526 - Fujitsu Report Horizon Data Integrity v1.0, https://www.postofficehorizoninquiry.org.uk/evidence/fuj00080526-fujitsu-report-horizon-data-integrity-v10 https://www.postofficehorizoninquiry.org.uk/evidence/fuj0008... [2] WITN00780100 - Richard Roll - Witness Statement.pdf >[...]there were several different types of configuration, depending on the type of PO (mobile, single counter, multi counter or main PO with a separate gateway computer), but from the SPM's perspective these would have all looked the same. >General security protocols were in place at the PO's. Secure passwords were required, which were not supposed to be shared but often were. There was a secure link from the PO counter to Fujitsu's servers —the counters would only respond to requests originating from specific telephone numbers —and all data was encrypted. Additionally, the network was completely (logically) isolated form the internet, it had its own dedicated lines[...]
- codeulike 3y ago