Been thinking this would be worth trying for a while now. Set a config option for syncprov to send Persist messages to a multicast group instead of the original TCP session. All the consumers would also join the group and listen for updates. This would also exercise the cldap:// support in libldap.
Implementation details: since datagrams are unreliable, we need to include sequence numbers on each message, which the consumer can check to make sure it hasn't missed an update. Moreover, it should be able to send a request to the provider to resend (over the TCP session) the message corresponding to a given sequence number.
(Currently I envision using a small circular array in the provider to remember the last N messages for potential retransmit.)
Config: both consumer and provider will need to be configured with a particular multicast group ID. It should be possible to participate in more than 1 group at a time (in which case, an update must be explicitly sent to each active group) but in general, I expect a cluster of cooperating MMR servers to all use a single multicast group, and so any update will only need to be forwarded to the network once.
Thoughts?
On Sun, Feb 08, 2015 at 12:52:40PM +0000, Howard Chu wrote:
Been thinking this would be worth trying for a while now. Set a config option for syncprov to send Persist messages to a multicast group instead of the original TCP session. All the consumers would also join the group and listen for updates. This would also exercise the cldap:// support in libldap.
It certainly makes sense to have the network do more of the work where it can. This would be particularly valuable in the high fan-out case.
Encryption and message signing needs some thought - this is usually harder to get right in datagram protocols than in streams.
While we are talking datagrams and multicast, have you looked at Fountain Codes? It seems to me that they would be an ideal way to initialise a large set of replica servers. They could also be used in the persist update case, avoiding the need for any sort of back-channel.
For those who have not met them, Fountain Codes allow you to broadcast large datasets to an unknown number of receivers over lossy channels. If well designed, each receiver needs to collect any randomly-chosen subset of datagrams adding up to a few percent more bytes than the source data. One such code is described in RFC5053, though there appear to be patent issues to be considered.
Andrew
Andrew Findlay wrote:
On Sun, Feb 08, 2015 at 12:52:40PM +0000, Howard Chu wrote:
Been thinking this would be worth trying for a while now. Set a config option for syncprov to send Persist messages to a multicast group instead of the original TCP session. All the consumers would also join the group and listen for updates. This would also exercise the cldap:// support in libldap.
It certainly makes sense to have the network do more of the work where it can. This would be particularly valuable in the high fan-out case.
Encryption and message signing needs some thought - this is usually harder to get right in datagram protocols than in streams.
While we are talking datagrams and multicast, have you looked at Fountain Codes? It seems to me that they would be an ideal way to initialise a large set of replica servers. They could also be used in the persist update case, avoiding the need for any sort of back-channel.
Interesting reading. Seems a bit of overkill to me though; that's designed for multicast to millions of subscribers where a back-channel isn't feasible. Syncrepl would never be used with such a high fanout, and we already have the back-channel anyway, why not keep using it?
For those who have not met them, Fountain Codes allow you to broadcast large datasets to an unknown number of receivers over lossy channels. If well designed, each receiver needs to collect any randomly-chosen subset of datagrams adding up to a few percent more bytes than the source data. One such code is described in RFC5053, though there appear to be patent issues to be considered.
Andrew
-
Andrew Findlay -
Howard Chu