From owner-freebsd-cluster@FreeBSD.ORG Fri Dec 10 13:11:09 2004 Return-Path: Delivered-To: freebsd-cluster@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F5B716A4CE for ; Fri, 10 Dec 2004 13:11:09 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BFA343D48 for ; Fri, 10 Dec 2004 13:11:08 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.26] ([192.168.1.26]) (authenticated bits=0) by web.portaone.com (8.12.11/8.12.11) with ESMTP id iBADB37Z006670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2004 14:11:05 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41B9A060.80003@portaone.com> Date: Fri, 10 Dec 2004 15:10:56 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: evg_dolgop@mail.ru References: <200412101422.48641.dolgop@mccinet.ru> <41B98A31.1090703@portaone.com> <200412101545.46048.dolgop@mccinet.ru> In-Reply-To: <200412101545.46048.dolgop@mccinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: freebsd-cluster Subject: Re: ng_one2many heartbeat algorithm for LAN fault tolerance X-BeenThere: freebsd-cluster@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Clustering FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 13:11:09 -0000 Well, I've took closer look at the patch today and found that two things need to be done to get it to the commitable shape: 1. Make it working independently of the layer on which one2many operates. For example, I use it for doing ip-over-udp multilink tunnel between two points. Since one2many is protocol agnostic heartbeat feature should not make any assumptions regarding type of protocol (e.g. ethernet, ip, udp etc). This is not trivial, I know, maybe the best way to address it is to make content of heartbeat packet configurable, so that one can put in whatever is appropriate for his task. Then you can put guidelines about configuring it for ethernet into man page. For example, in my situation I can put single 0 byte as a heartbeat payloas since it will be used as a payload to UDP packet, so that no real header is necessary. 2. It would be very nice to extend heartbeat algorithm with recovery function, so that it will keep sending heartbeats over links that were detected as dead ones previously to see if any of them have recovered. Please let me know what do you think about it. Regards, Maxim Evgeny Dolgopiat wrote: > Ok. Do you need something from me (some patches, docs etc.)? > > >>I can after some testing. ;-) >> >>-Maxim > > > >