Re: [tipc-discussion] [PATCH net-next 0/3] fix broadcast sync issue

[jason <huz...@gm...>]

Hi Ying,
It seems there is a problem about this patch. If peer lost contact before
sending the new bcast sync message to us, then we will not be able to call
tipc_bclink_remove_node() in node_lost_contact() because it is called only
if bclink.supported is set. That will cause a wrong node map count then
bclink will become stall.
On Jan 31, 2013 6:06 PM, "Ying Xue" <yin...@wi...> wrote:

> jason wrote:
>
>>
>>
>> Hi Ying,
>> Sorry to turn this old thread out. But with tipc-1.7.7 we encountered
>> name table not matching between nodes several times. Can this be a
>> consequence of the first issue you listed?
>>
>
>
> Yes, the first risk can turn out to be not synced for name table.
>
> Regards,
> Ying
>
>  Thank you!
>>
>> On Jul 3, 2012 3:53 PM, "Ying Xue" <yin...@wi... <mailto:
>> yin...@wi...**>> wrote:
>>
>>     Currently there have two major known issues about broadcast link as
>>     belows:
>>
>>     1. There has one risk that name table updates sent over the broadcast
>>     link after the neighbor is discovered will arrive before the initial
>>     transfer of name table entries over the unicast link has been
>> completed.
>>
>>     2. There has another risk that the node may send a broadcast message
>>     after the neighbor is discovered without being certain whether the
>>     neighbor will acknowledge it or not.
>>
>>     To resolve above issues, we introduce a new BCAST_PROTOCOL, and send
>>     that immediately after name table messages have been sent via reliable
>>     unicast link. This message contains the sequence number of the most
>>     recent broadcast message the sending node has sent, telling the
>>     neighbor node when to start accepting broadcast messages and where to
>>     start receiving and acknowledging broadcast messages.
>>
>>     In addition, to keep protocol compatibility backwards, we also involve
>>     a flag bit to indicate whether a node supports the enhanced broadcast
>>     synchronization mechanism or not.
>>
>>     Ying Xue (3):
>>       tipc: Add a new flag bit to indicate bclink sync protocol is
>>         supported
>>       tipc: Keep protocol compatability backwards
>>       tipc: Involve the enhanced broadcast synchronization mechanism
>>
>>      net/tipc/bcast.c      |   23 ++++++++++++++++++++++
>>      net/tipc/bcast.h      |    1 +
>>      net/tipc/link.c       |   50
>>     ++++++++++++++++++++++++++++++**++++++++++++++++++-
>>      net/tipc/link.h       |    1 +
>>      net/tipc/msg.h        |   10 +++++++++
>>      net/tipc/name_distr.c |    1 +
>>      net/tipc/node.c       |    5 ++-
>>      net/tipc/node.h       |    2 +
>>      8 files changed, 90 insertions(+), 3 deletions(-)
>>
>>
>>     ------------------------------**------------------------------**
>> ------------------
>>     Live Security Virtual Conference
>>     Exclusive live event will cover all the ways today's security and
>>     threat landscape has changed and how IT managers can respond.
>>     Discussions
>>     will include endpoint security, mobile security and the latest in
>>     malware
>>     threats. http://www.accelacomm.com/jaw/**sfrnl04242012/114/50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>     ______________________________**_________________
>>     tipc-discussion mailing list
>>     tipc-discussion@lists.**sourceforge.net<tip...@li...>
>>     <mailto:tipc-discussion@lists.**sourceforge.net<tip...@li...>
>> >
>>     https://lists.sourceforge.net/**lists/listinfo/tipc-discussion<https://lists.sourceforge.net/lists/listinfo/tipc-discussion>
>>
>>
>