melizalab/decide-rs

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

Starting and killing decide-core multiple times in a row generates a chain of errors and requires a re-logon to access the beaglebone again:

This negatively impacts beaglebone performance afterwards.

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.