Horvath, Elmer <[EMAIL PROTECTED]> wrote:
> The incorrect calculation for us was in tipc_link.c in the routine
> link_recv_proto_msg() calculating the value of the variable 'rec_gap'. The
> code is:
> if (less_eq(mod(l_ptr->next_in_no), msg_next_sent(msg))) {
> rec_gap = mod(msg_next_sent(msg) -
> mod(l_ptr->next_in_no));
> }
>
> This resulted in rec_gap being non-zero even though both operands were the
> same value. When rec_gap is non-zero, then tipc_link_send_proto_msg() is
> called with a non-zero gap value a bit further down in the same routine.
Are there any protocol-inherent restrictins regarding the values of
msg_next_sent() and ->next_in_no?
Because according to less_eq(), both
1 <= 32769
and
32769 <= 1
are false.
Also,
2 <= 32768 is true, but
2 <= 32770 isn't.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
