Difference between revisions of "SafeCode"
From Hackstrich
(Lots of work on the train :)) |
|||
Line 2: | Line 2: | ||
= Project Status = | = Project Status = | ||
+ | * 2013-06-09: Refactored web service to use a proper state machine, which only allows valid state transitions. Next steps are to finish implementing end-to-end monitoring and add reconnection attempts to everything. | ||
* 2013-06-07: Broke out hardware drivers into modules separate from the daemon itself, and wrote a simulator for testing w/o real hardware. Implemented responses from web service to daemon so the box can display the state/last command status. Next step is to clean up the allowed state transitions and finish implementing end-to-end monitoring. | * 2013-06-07: Broke out hardware drivers into modules separate from the daemon itself, and wrote a simulator for testing w/o real hardware. Implemented responses from web service to daemon so the box can display the state/last command status. Next step is to clean up the allowed state transitions and finish implementing end-to-end monitoring. | ||
* 2013-06-05: Added reconnection to the SafeCode Box when the connection is lost. | * 2013-06-05: Added reconnection to the SafeCode Box when the connection is lost. |
Revision as of 22:15, 9 June 2013
SafeCode is a software/hardware solution to handle digital safe-calls for independent in-call sex work.
Contents
Project Status
- 2013-06-09: Refactored web service to use a proper state machine, which only allows valid state transitions. Next steps are to finish implementing end-to-end monitoring and add reconnection attempts to everything.
- 2013-06-07: Broke out hardware drivers into modules separate from the daemon itself, and wrote a simulator for testing w/o real hardware. Implemented responses from web service to daemon so the box can display the state/last command status. Next step is to clean up the allowed state transitions and finish implementing end-to-end monitoring.
- 2013-06-05: Added reconnection to the SafeCode Box when the connection is lost.
- 2013-06-04: Moved all logic into the web service, daemon just sends events (client arriving, check in, check out) now. Decoupled monitoring client screen updates from packets, now timer free-runs in between received packets. Implemented a display of last communication and alerts when communications are lost.
- 2013-06-03: Got a prototype box up using an Arduino + TouchShield, can now log in to a session successfully. I've kind of got "business logic" spread between the web service and daemon now, next step is to move all of that into the web service, daemon should just be hardware interfacing and keepalive.
- 2013-06-02: Started writing software. Frontend now loads and connects to the web service, as does the backend daemon. Still have some cleanup/reliability improvements to do, but basic functionality is there (minus hardware interfacing).
- 2013-06-01: Started thinking about/planning.
Hardware
- Small/portable box
- Rugged design, as it will be thrown in bags/traveled with constantly
- USB connected/powered
- Keypad on top to enter data (Storm 6000-21001, telephone-style 12 key + Cancel, Clear, Help, Enter)
- Lighting to provide feedback for "entry received" and such
- Beeper for indicating exceeding check-in time without checking in
Software
- Daemon that runs on the local machine talking to the SafeCode box
- Web service that runs on an outside server that reports status to others
- Keepalives between all components to indicate that a connection was broken
Web Service Architecture
- Sinatra-based daemon
- Accepts WebSocket connections from the daemon talking to the SafeCode box and monitors to ensure that connection stays open and that keepalives are being received
- Serves web pages & uses WebSockets to update status in real-time for anyone monitoring
- Keeps state of:
- Current geographical location
- Connectivity to daemon
- Daemon's connectivity to the SafeCode box
- Session state
- Not in session
- Client arrived, no check-in yet
- Check-in OK, in session
- Check-in non-OK, in session
- Time of next expected check-in (if in session)
Daemon to Web Service Protocol
- JSON-based
- Command
- event - client_arrived, check_in, check_out
- code - string
- length - numeric (only implemented for check_in)
- distress - true/false (only implemented for check_in)
- Response
- status - accepted, error, distress
- Command