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

[Jon M. <jon...@er...>]

On 03/08/2013 11:06 AM, jason wrote:
> Hi Jon,
> Thank you for the detailed explanation very much. It is the step 2 that
> answered my concern. In step 2 of your scenario, if node B do not set
> next_in = N -1, then B will have the invalid bcast_ack issue that I
> described.

You're welcome. 
It was actually a useful exercise for me to revisit the algorithm,
because I spotted something else that we probably should fix.

At step 7 in my description (pasted in below) I realized that node B
may receive broadcast packets that were sent from A *before* the link
was established. Sequence number N in the example is the state when
A sends out its ACTIVATE message, not the state when the link is 
established in A and the BCAST_SYNC is sent.

This will work fine, of course, and I am not sure it is a real problem.
But it would probably be more correct to let BCAST_SYNC carry a 
last_bcast = (N + x) instead, i.e. the value of next_out_no -1 at the 
moment of establishing the link. I'll have to consider this.

Regards
///jon

> 
> I am currently using tipc-1.7.7 and  assume that Ying's patch at the
> beginning of this thread is the final version for tipc-1.7.7 to introduce
> this new bcast sync mechanism, so all my concerns are base on tipc-1.7.7
> plus this patch. Do you have plan to update 1.7.7 to include the final
> version of this new bcast sync mechanism in future? Or I have to switch to
> netdev version to have it?
> 
I think Ying is the right person to answer on this.

///jon

0: Node A has next_out_no N, Node B has next_out_no M

    1: Node A sends an ACTIVATE message to B, where last_bcast = N -1,
       effectively telling B it to start acking broadcast packets from that
       sequence number.

    2: Node B receives the ACTIVATE, activates its link endpoint, and
        sets last_in = N -1.
        Note that B is not open for receiving broadcasts yet, and does not 
        know where to start receiving. It only knows which bcast_ack value 
        to  send in its unicasts.

   ( 2.5: Node A and B may now send out more broadcasts, but A doesn't 
        expect any acknowledges from A, or vice versa, since neither node is
       in the peer's broadcast receiver's list.
       Below, I'll assume that no broadcasts are sent, since this doesn't
       affect the reasoning.)

    3: Node B sends a BCAST_SYNC as *first* unicast message to A. This 
       message contains bcast_ack = N -1 ,  and last_bcast = M - 1, 
       meaning that A should start receiving from M.

    4: Node A receives the BCAST_SYNC message and opens up to start 
       receiving from packet M from node B, setting last_in = M -1.  
       The bcast_ack value from B  is ignored, since it is lower than N.  

      We are now in the the situation you describe in your example.
      As you see, all values are strictly defined and valid.



     5: Node B goes on sending NAME_DISTR messages after the BCAST_SYNC
        was sent. Those will all contain bcast_ack = N -1, since B cannot
        have received any broadcast messages until it has received its own
        BCAST_SYNC. All those acks will be ignored by A, as described above.

     6: Node B may now also send broadcasts M, M + 1 etc. to A, which A 
        will receive and deliver, but A will send no acks before its  own 
       BCAST_SYNC has been sent out.

     7: Node A sends a BCAST_SYNC as first unicast message to B. It carries 
        bcast_ack = M - 1  (or M + x  if some broadcasts were received). 
        This is now a valid ack value.  last_bcast = N - 1 (disregarding that A may 
       already have  sent N, N+1 etc)

     8: Node B receives the BCAST_SYNC, finds it can (and must) start 
        receiving from N, and open up for reception. If A has already
        sent N + 1,  N + 2 etc, Node B will either have them in its
        deferred queue, or it will have to ask for retransmission.