Simplify PUB-SUB base types

[machinekoder]

Currently we use one type per PUB-SUB socket. Meaning the launcher service uses for example the MT_LAUNCHER_FULL_UPDATE message and the halrcomp service uses the MT_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 and MT_INCREMENTAL_UPDATE messages would drastically simplify the implementation of generic language bindings.

[mhaberler]

yes, that was overspecified. The message topic and content is good enough to differentiate.

[machinekoder]

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)

[mhaberler]

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

[machinekoder]

Yes, there are some design problems with the current protocol that should be addressed:

• relying on the SUBSCRIBE message assumes we only use unicast transports with feedback
• a PUB sockets can drop messages, a client has currently no way to find out if a message was dropped (no sequence number)
• Updating a pin from the client uses an RPC call with feedback whereas updates from the server use published messages. Even if SUBSCRIBE would work with multicast this would assume we a use a different transport for the client to server direction.
• The protocol always assumes a server-to-client relation which gives us a single point of failure. Therefore, this protocol is not suitable to sync two or more HAL instances in a decentralized way.

To solve these problem I propose a new state sync protocol.