| Overview |  |
The Machi FLU file server + file location sequencer.
This module implements only the Machi FLU file server and its implicit sequencer. Please see the EDoc "Overview" for details about the FLU as a primitive file server process vs. the larger Machi design of a FLU as a sequencer + file server + chain manager group of processes.
The FLU is named after the CORFU server "FLU" or "FLash Unit" server.
The protocol implemented here is an artisanal, hand-crafted, silly thing that was very quick to put together for a "demo day" proof of concept. It will almost certainly be replaced with something else, both in terms of wire format and better code separation of serialization/deserialization vs. network transport management, etc.
For the moment, this module implements a rudimentary TCP-based protocol as the sole supported access method to the server, sequencer, and projection store. Conceptually, those three services are independent and ought to have their own protocols. As a practical matter, there is no need for wire protocol compatibility. Furthermore, from the perspective of failure detection, it is very convenient that all three FLU-related services are accessed using the same single TCP port.
TODO There is a major missing feature in this FLU implementation: there is no "write-once" enforcement for any position in a Machi file. At the moment, we rely on correct behavior of the client & the sequencer to avoid overwriting data. In the Real World, however, all Machi file data is supposed to be exactly write-once to avoid problems with bugs, wire protocol corruption, malicious clients, etc.
TODO The per-file metadata tuple store is missing from this implementation.
TODO Section 4.1 ("The FLU") of the Machi design doc suggests that the FLU keep track of the epoch number of the last file write (and perhaps last metadata write), as an optimization for inter-FLU data replication/chain repair.
TODO Section 4.2 ("The Sequencer") says that the sequencer must change its file assignments to new & unique names whenever we move to wedge state. This is not yet implemented. In the current Erlang process scheme (which will probably be changing soon), a simple implementation would stop all existing processes that are running run_seq_append_server().| make_listener_regname/1 | |
| make_projection_server_regname/1 | |
| start_link/1 | |
| stop/1 | |
| update_wedge_state/3 |
make_listener_regname(BaseName) -> any()
make_projection_server_regname(BaseName) -> any()
start_link(Rest) -> any()
stop(Pid) -> any()
update_wedge_state(PidSpec, Boolean, EpochId) -> any()
Generated by EDoc, May 20 2015, 12:58:33.