Technical specification for reliable bidirectional data transport between installed hardware component and client representation in SecondLife.

Anne Ogborn

Switch positions of the 'knobs' in the installed hardware will be read by
serial scan into a set of parallel shift registers, one per note. Parallel data
will be read into a standard PC through LPT1: operating in STANDARD mode, by feeding data through handshake lines via MUX.

Power supply for PC and custom hardware will be ganged to a single 110VAC
supply line with a reset switch, so that museum personnel can reset the system as required.

PC will operate Windows XP and 1.6JRE. Custom J2SE application will operate as a server, tieing into existing Tech Museum network infrastructure. System will operate an HTTP subset on a nonreserved port.

SL LSL script executing on Linden Labs server (this is normal script operation,
not something special) will periodically execute via llHTTPRequest an HTTP GET request with an encoded set of all state changes in controls within SL in the query string, and a sequence number.

PC server will respond with a most-recent state, and a sequence number. The PC is master.
Each successive response will be encoded with an incremented sequence number.
Sequence numbers should start at the System.currentTimeMillis() time at
startup. Since it is beyond network performance to transmit one
transaction/millisec, this ensures that sequence numbers are strictly
sequential. Caution should be taken on the LSL end to ensure that the sequence
number does not overflow.

In summary - data is locally cached MVC pattern with the master data on the PC.
Data transport from SL to RL is via the HTTP GET query string, from RL to SL
via the HTTP response body