Hi Florian,
The intention with less() is that
(x - 32767) < x < (x + 32767)
or put in a different way
0 < 32767
32769 < 0
Effectively, this leaves out the case when the two
parameters are exactly 32768 numbers apart,
which will give always return false, irrespective
of parameter order, as it will even for less_eq().
This is clearly mathematically incorrect, but I never
saw this as a problem, since the send window
will never reach this size, -the important thing here
is an efficient algorithm. And anyway, a false
positive now and then would not do any harm to
the protocol.
If you can come up with something better and
and equally efficient, you are welcome, but I don't
think this is the core of our problem.
Regards
///jon
Florian Westphal wrote:
> 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
>
-------------------------------------------------------------------------
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
