Peter Williams wrote:
If I think out loud about train stations, and football stadiums, and the like:
PCSCd event and process archirtecture really needs updating, to use UNIX in a way that suits thread pooling, not static threading for USB or RS22C connected reader.
if a mifare reader is in a public place, like the entrance to a train gate, and is rapidly scanning passengers' RFIDs as they bustle past the scanner, the infrastructure supporting the reader needs
a) to be able to address multiple cards on the mifare "bus" at the same time,
b) spawn n contexts, from a PCSCd pool manager, for each of the n ISO 7816-3 data-capable RFIDs in range.
If all readers are connected synchronously to a central machine, for each station/stadium, you can imagne a UNISYS class IO plane, supporting the unix process architecture, to handle the io created.
At a local reader,
For (a), we have to recognize that there will be setup collisions, given the nature of people to rush by, all together, thus context setup must be fast. (multple sensors may be required at dfferent locations, to try and catch all who rush by, for even intelligence-grade IO processing rates)
For (b) we have to account for the fact that many cards could be repeatedly read, if folks hang around the sensor location. Its going
to be hard t know when to release the context, for a given RFID hit.
lets note that RFIDs in tickets will be anonymously scanned: its not
that you "present" the ticket, to show entitlement. its a tracking system, not a presentment system, note. So reader and infrastructure
architecture needs to evolve for these anonymous, event-generating dynamics.
---
The io bus design problem above is really the same as the "academic" mifare-based parallellised code breaker, key enumerator machine (where you have n*1000 mifare-enabled code crackers on a std component spool with 1000 devices per tape. (Someone in China has apparently tried to build this, BTW!). If there are multiple streams of tapes, each within range an RF power source, and each bearing a mifare-enabled javacard, for example, as the tape of cards is spooled throgh a result-collation reader, at velocity v, the io has to know quickly that some cards may have results, and some may not: so the io parameters of the bus design are much the same as in train/stadium reader design.
Solve one, you solve the other.
Peter,
Whether you used a train station gate (with your mag stripe ticket) while over here in the UK recently, I don't know. Odds were that it was a Cubic gate. Their smart card version (used in London) has a PC in each gate and a max of 2 readers per bi-directional gate. Their reader is a sophisticated DSP device.
But a football stadium is a much more interesting configuration as the subject of your proposal.
Peter
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
