[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:06:17 +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=MtUjrjyw2lzlB/mwRpE/bBk0Ch7opkjAZFyDG29zYBY=; b=zN5nRCwkfp99ARq9R0mqykeorEEaJehSYhUQS3DNlMKBp9XcLEf3Yc4P98KR1vRHKF peg6rwSXrvN8OZEwvBrr2FI/LrssFaVGvUiUCmVnGWp/93r7yb1YbZPcNDPQJ21QNFxG dnitpMsCqS039U2fapgzJ//sWddlAoF06zgjUZ95skj4ru5FvGWv6icmkctry0zI1b8D zju0zP9Dradl5rdKS0u9X2MVhYuPEA95++ofZ92V3kgl2CuzHvwSo3gWoyk2TB91RefK qdRMZ6aWV5/5dBfXdkcKgjFvGs/bpcuG5Oq7A2+n9U4S23wFgz3sSEKTQPdaFcmPI6Nq SXXA==
- 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.
A heart-beat would be good to have : the producer would periodically
multi-cast the latest CSN, allowing desynchronized servers to catch up.
Another pb iw that Datagram are limited in size, which means big entries
will have to be split in many parts.