From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Marek Lindner Date: Thu, 10 May 2012 21:12:37 +0800 References: <20120504000852.GA29070@ritirata.org> In-Reply-To: <20120504000852.GA29070@ritirata.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205102112.37690.lindner_marek@yahoo.de> Subject: Re: [B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: The list for a Better Approach To Mobile Ad-hoc Networking Hi, > Right now I am working on a concept that would enable such possibility. I > tried to summarise my ideas on the wiki as well[1] in order to share with > you the solution I am thinking about. > > The document is still a draft and may not be 100% understandable. If you > have time and you are curious enough to read the wiki, please drop me your > feedback, it would really be appreciated :-) if I understand the document correctly each mesh node a client connects to will send a roaming advertisement back to the last known mesh node this client was connected to. A few questions come to my mind: * Does this already work with the current code ? If not what happens now ? * How do all nodes get back in sync ? It sounds to me like for certain while a number of nodes claim the same client, right ? Nobody tells the intermediate mesh nodes that their client has moved. * What if receiving a roaming advertisement triggered an immediate (unscheduled) OGM broadcast ? That would potentially speed up the gap and also address the "longer path" problem you outlined in the wikipage. Regards, Marek