[zeromq-dev] 12/CHP - Clustered Hashmap Protocol ...

[Pieter Hintjens]

Hi Marten,

The changes sound fine... we in fact switched to the pull request
model for protocols too, https://github.com/zeromq/rfc

So you can make your proposed changes there. If you want to change the
actual protocol we need to updated the various implementations as
well.

Cheers
Pieter



On Thu, Apr 11, 2013 at 2:32 PM, Marten Feldtmann
<itlists at schrievkrom.de> wrote:
> Hey,
>
> I'm trying to implement this protocol and have some question regarding
> to the protocol:
>
> a) The client has a subscriber connection to the server. Should the
> "subtree specification" used in the state synchronization set as a
> filter in the subscriber connection - otherwise the client get all
> changes, though it initially mentioned to be interested only in a
> subtree of the overall hashmap ?
>
> That would also indicate, that commands "KVPUB" and "KVSET" must follow
> this way ...
>
> And to get the HUGZ command one must set at least two filter
> informations on the subscriber channel.
>
> Without these filters the clients may get equally named keys from
> different subtrees and can not decide, what the correct one is.
>
> b) A problematic situation arrises when switching from state
> synchronization to "normal subscriber message receiving". There is a
> possible gap, where a message (suitable for this client comes in) can
> get lost. The client may close the snapshot socket and opens the
> subscriber socket - but perhaps too late and it does not get the message
> mentioned above.
>
> A solution might be, that the client subscribes to the server before it
> does a state synchronization - he may get additional messages but
> nothing gets lost.
>
> c) KTHXBAI-Command: Would it better, if the server sends its actual
> sequence number and not the one he uses in KVSYNC commands. Then the
> client know, what he can throw away and it knows its server
> corresponding sequence number.
>
> d) "HUGZ" command - should the "Frame 1" be better described as "8 bytes
> all filled with numeric value 0".
>
>
> Any comments about these ideas ?
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev