Open machinekoder opened 8 years ago
yes, that was overspecified. The message topic and content is good enough to differentiate.
If the "sync pattern" is restructured to use PUB-SUB in both directions and the client also used MT_INCREMENTAL_UPDATE
to update values then synchronizing without a master is possible.
Use case: decentralized storage, two haltalk instances talking to each other (on different machines)
hm, interesting
any chance of describing the protocol as a flow, like in https://github.com/mhaberler/asciidoc-sandbox/wiki/Remote-HAL-Components#halrcomp-protocol-overview ?
btw I use http://www.mcternan.me.uk/mscgen/ for doing the sequence dias
Yes, there are some design problems with the current protocol that should be addressed:
To solve these problem I propose a new state sync protocol.
Currently we use one type per PUB-SUB socket. Meaning the
launcher
service uses for example theMT_LAUNCHER_FULL_UPDATE
message and thehalrcomp
service uses theMT_HALRCOMP_FULL_UPDATE
message. That means every service needs to add new types to Container message. That would make sense if all message would be piped on the same stream. However, the service topics are already used to distinguish between different sources.Defining generic
MT_FULL_UPDATE
andMT_INCREMENTAL_UPDATE
messages would drastically simplify the implementation of generic language bindings.