On Mon, Apr 20, 2009 at 1:15 PM, Luca Dionisi <[email protected]> wrote:
> On Mon, Apr 20, 2009 at 11:56 AM, Luca Dionisi <[email protected]> wrote:
>> I built a rudimentary test suite [1] for the exec_etp method of Etp class.
>>
>> When I run the test I obtain the attached output [2].
>>
>> Assume a simple network, composed by nodes belonging to the same gnode.
>> Let theirs IP be 192.168.1.*
>> Assume this topology
>> 9 <---> 1 <---> 15 <---> 4
>> RTT(9,1) = 55
>> RTT(1,15) = 123
>> RTT(15,4) = 100
>>
>> Suppose that node 15, which already knows a route towards 4, detects
>> the link towards 1 and produces a ETP and sends it to 1.
>> At this moment, the test suite examines the ETP processing done by
>> node 1 and then by node 9.
>>
>> What appears from the output is that the resulting maproutes are wrong.
>> Before doing some deeper debug, I would like to ask what are the
>> expected results.
>>
>> 1)
>> The portion R of the ETP forwarded through the chain of nodes, does
>> not change. I could assume that it always represents the portion of
>> map how it is seen by the first producer of the ETP. The receiver of
>> the ETP may know who the first producer is, and how far it is from
>> him, by reading the TPL.
>> Is this right? Or should the portion R change?
>>
>> 2)
>> The node 1 changed its maproute appropriately.
>> It has updated it basing on R. The TPL part is void indeed.
>>
>> 3)
>> The node 9 changed its maproute not appropriately.
>> It has updated it basing on R + TPL. The Rems are summed in the wrong order.
>>
>>
>> [1] attachment test_qspn.py
>> [2] attachment output_test_qspn.txt
>>
>> --Luca Dionisi
>>
>
> Applying this [1] little patch I fixed the behavior for the previous
> topology, where all nodes belong to the same gnode of level 1.
> Now the attached [2] test suite, with new nodes from other gnodes,
> produces attached log [3]
>
> Note that when node 10.0.0.1 processes the ETP and forwards it, the
> REM 178 (useless) is retained, while the REM 40 (its link with
> 192.168.1.9) is discarded.
>
> I think that in the TPL the only rem set to None should be in the
> first pair of the first block. And that the first pair of the other
> blocks should contain the REM for the link towards the previous block.
> Am I right?
>
>
>
> [1] revert_sum_rem.patch
> [2] attachment test_qspn.py
> [3] attachment output_test_qspn.txt
>
> --Luca
>
Iff the previous mails sound correct, please consider applying the
attached global patch.
--Luca
Index: pyntk/ntk/core/qspn.py
===================================================================
--- pyntk/ntk/core/qspn.py (revision 1572)
+++ pyntk/ntk/core/qspn.py (working copy)
@@ -198,17 +198,24 @@
return # drop the pkt
##
+ ## The rem for the first pair of the first block is useless.
+ TPL[0][1][0][1] = NullRem()
+ ##
+
old_node_nb = self.maproute.node_nb[:]
## Update the map from the TPL
tprem=gwrem
TPL_is_interesting=0
- for block in TPL:
- lvl=block[0]
- for dst, rem in block[1]:
- tprem+=rem # TODO: sometimes rem is an integer
+ for j in xrange(len(TPL)-1, -1, -1):
+ block = TPL[j]
+ lvl = block[0]
+ TP = block[1]
+ for i in xrange(len(TP)-1, -1, -1):
+ dst, rem = TP[i]
if self.maproute.route_change(lvl, dst, gw, tprem):
TPL_is_interesting+=1
+ tprem+=rem # TODO: sometimes rem is an integer
##
## Update the map from R
@@ -250,7 +257,7 @@
if not is_listlist_empty(R2) or TPL_is_interesting:
if TPL[-1][0] != 0:
# The last block isn't of level 0. Let's add a new block
- TP = [[self.maproute.me[0], NullRem()]]
+ TP = [[self.maproute.me[0], gwrem]]
TPL.append([0, TP])
else:
# The last block is of level 0. We can append our ID
_______________________________________________
Netsukuku mailing list
[email protected]
http://lists.dyne.org/mailman/listinfo/netsukuku
