Currently, the topology looks like this:
server–> pool manager --> columns.
Each part is its own process, using the BEAM VM’s concept of lighweight threads. Each process holds its own state, and communicates with others via messaging. This allows each column to act as an independent entity, which makes modelling a bit easier. Where Elixir is built on top of Erlang, and Erlang’s BEAM VM already includes the ability to scale and distribute work across hosts, reducing the amount of engineering we’d have to do. The VM automatically distributes processes across all the cores in a system, and across the hosts whenever a new node is added.
Current process flow:
encoder(s) ---- SDR —> pool —(broadcast message)–> column(s); check overlaps and predictive state
pool <—(connection count messages)— column(s)
pool —(to winners)—> column(s): strengthen overlap connections; if in predictive state, strengthen. If not, burst.
Update pool state, so that it is able to be queried from remote host
Planned expansions: remote callbacks for “IO block system” (state machine which amplifies/dampens pool’s connections to IO block depending on current state, whose parameters can be configurable).
Intended use is for writing controllers for simulators, where controller would encode simulator conditions and send SDRs to pool server, which would then asynchronously send a callback with output data. Using this model, could even connect to robotics projects using something like ESP32 or its cousins for real world experiments.
Anyway, had actual work come in yesterday afternoon, which might throw back my repo setup just a bit. I’ll revive that old thread when I get my code up.