decide-rs's People
decide-rs's Issues
Controller freezes up when hit with too many requests at once
Not sure exactly what's going on here (and it will be hard to debug), but when all the tests run at once, they never finish, even though every single one will finish if run individually. See fe7b7aa for an example of this happening. Could be a tokio/multithreading issue
Python client library
peckboard component
`is_valid` method in Component trait
We can separate some concerns and nudge component authors to think more about their state space by requiring a is_valid(State) -> bool
method and performing this check before passing any state change requests to components. (This check would normally be performed by components in their changeState implementation.) By breaking this logic out, we can make our "message is well formatted and is about to be acted upon" confirmation reply more meaningful (right now, components can still complain that the message is poorly formatted after the controller has replied with a confirmation).
syslogd internal error
Different apparatus checking flow
Notes from my meeting with Dan.
Changes to be implemented:
- new request type
get_component_list
returns names and types of every component acquire_lock
no longer requires arguments, clients should only call this if they have verified their compatibility with the component list
Advantages of this flow over the currently implemented one:
- clients are insensitive to hardware specific changes (e.g. interrupt lines)
- clients can be insensitive to extra components that they don't use
- clients can be designed that can handle any configuration of components, like a web dashboard
stepper motor component
house lights component (sysfs)
Redesign spec for decide-ctrl
As part of reimplementing decide-ctrl, we are changing the wire protocol for processes to communicate with the controller, from http/websockets to zeromq. This gives us the opportunity to revisit how the messages are encoded.
This thread is to discuss some of the issues around the spec.
At @jonahweissman's suggestion, we're going to move away from encoding the messages in JSON. This removes the need for the controller to do a lot of parsing of the messages. We can use zeromq framing to define message types and then send the payload as a protocol buffer.
The general format of a request:
- Frame 0: Empty (zero bytes, invisible to REQ application)
- Frame 1: "DCDC01" (six bytes, representing decide/control v0.1)
- Frame 2: Request type (one byte)
- Frame 3: Component name (string)
- Frame 4: Request body (protocol buffer)
An example of a request type would be an instruction to change the state of a component. The type might be 0x01, the name would be given in the next frame, and the requested state would be delivered in the payload. But different components will have different kinds of state. Integers will work for lights, peck detectors, motors, but we need strings for stimulus playback.
We'd also need a request type for changing parameters, and those would be even more component-dependent.
I think this is a good way to proceed, but we have to solve the issue of how the client knows what message type to use for each component. Do we just write down a bunch of .proto
definitions that we use for code generation in writing the clients? Or can we design a mechanism for the client to discover the protocols?
Single socket for both pubs and replies
Combining the socket for pubs and replies would allow us to guarantee that all "request is well formatted" confirmations would be sent before the corresponding state update pub message
Graceful shutdown
Current implementation of the shutdown signal panics in the main task which abruptly ends all child tasks. This isn't really a problem right now, but sending a shutdown signal could be valuable if any future components need to perform a cleanup before shutting down.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.