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

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

Hi Ying and all,
Please help to understand this patch clearly:So as the new added handshake
flow, the name table updates sent over the broadcast link which arrive
before the initial transfer of name table entries over the unicast link
will be discard by the receiving node, then after name table unicast
finished, the receivng node will ask the sending node to retransmit it. Is
that theoretically right?.

Thanks a lot!
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>
>>
>>
>