[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl multicast MMR
- To: "openldap-devel@openldap.org >> OpenLDAP Devel" <openldap-devel@openldap.org>
- Subject: Re: syncrepl multicast MMR
- From: Emmanuel Lécharny <elecharny@gmail.com>
- Date: Mon, 09 Feb 2015 07:22:07 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kGbhNI0Db+9w8U3VaVanSeedSThjlVcSNZ7+lXYCjew=; b=WEK6RBtvQlPYR/VKJNItr1jIksBAKaZVVIZOy1/vsyjZadZ0qULLTGN7BMzkMfNhFN t6szNJfYTiOreE1zN7ookafFxOsBmLLPQHT9TdCmaKUEiSTMl5ih7eltWKE4GwKj09rZ L+0p0a0+xeTQJd5JZddw1dsn4/PPpjF0MqBYqWT/SKQXGqYqRvan9rxluqh91KWhC5uv sq7m5fMNaVonkaGW1Zes0UZNw1czI+tuEgmC/AliSsFDLtMxn3Txa/iwzKQ7ajg16xPE h4O5vDAS59Bk+3jax+vrBWvW12sgN8MVgi7rzOFXvYyvKkQfEu8arHhtsEkqqyZRdgrI 9GDg==
- In-reply-to: <54D83456.9000503@symas.com>
- References: <54D75C18.2050304@symas.com> <54D7B77C.3040703@gmail.com> <54D83456.9000503@symas.com>
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
Le 09/02/15 05:15, Howard Chu a écrit :
> Emmanuel Lécharny wrote:
>> Le 08/02/15 13:52, Howard Chu a écrit :
>>> 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.
>>
>> Ok but how do you detect that a consumer has missed an update, if no
>> other update occurs ? You may have some desunchronized server for quite
>> a long period of time if you don't have a mechinism for the consumer to
>> regularly check if it is up to date.
>
> Good point, but easily solved with a periodic keepalive msg.
One more thing : you will have to deal with TLS at some point. There is
a RFC draft
(https://tools.ietf.org/html/draft-keoh-tls-multicast-security-00) that
proposes something, it seems to be 3 years old, and not active anymore.