本文描述The ONE仿真器可能存在的一个bug,msgTtl
。建议使用以秒为单位来设置TTL。
1. Bug描述
我在Two-way Relay网络(A -- R -- B
)上做了个简单测试,节点A与B每隔5秒产生一个消息(MessageEventGenerator),updateIntervl
设为1秒(我稍微改了下The ONE源代码,每个updateInterval
所有节点只更新一次)。将msgTtl
设为2分钟时,得到如下结果:
sim_time: 200.0000 created: 80 started: 157 emissions: 157 nrofXor: 0 relayed: 156 aborted: 0 dropped: 0 removed: 0 delivered: 78 delivery_prob: 0.9750
结果符合逻辑。然而,将msgTtl
设为一分钟的时候,却得到这样的结果:
sim_time: 200.0000 created: 80 started: 79 emissions: 79 nrofXor: 0 relayed: 78 aborted: 0 dropped: 35 removed: 0 delivered: 39 delivery_prob: 0.4875
显然,不符合期望,因为一分钟的ttl,完全已经够了(实际上只需要5个unit time,A和B就可以将消息传输给彼此)。当我将msgTtl
设为10秒时,可以得到与2分钟一样的结果。坐等高人指点。
2. 设TTL以秒为单位
有了这次不合逻辑的仿真结果,强烈建议ttl设成以秒为单位。The ONE默认是分钟为单位,在设置文件添加如下行将ttl设成以秒为单位。
Scenario.ttlSeconds = true赞赏
微信赞赏
支付宝赞赏
我曾在微信群裡報告過這個bug,沒想到一年多以前您就已經發現這個bug了。真的好佩服!如果您有時間的話,希望您能把bug的相關代碼分析一下,這樣就能幫助大家了解到其背後的原因。謝謝。
关于这个BUG的代码分析,先按下不表。
public int getTtl() {
if (this.initTtl == INFINITE_TTL) {
return Integer.MAX_VALUE;
}
else {
return (int)( ((this.initTtl * 60) –
(SimClock.getTime()-this.timeCreated)) /60.0 );
}
}
是不是这里的原因
话说 有没有试着改回去试试不要让每个更新间隔 只更新一次改回 每次事件触发一次。。。反正现在 用的简单模型
这个问题比较纠结,想到现实网络,The ONE设计是合理的,有事件的话,就触发。没事件的话(相当于休眠),每隔一段时间,还是要总体更新一次。如果改成这样,是不是会更好:(1)有事件的时候,更新与事件相关的节点,如1 CONN 1 2 up,新建立一个连接,这时更新节点1和节点2。(2)再者,就是每隔一段时间,全部更新一次。还有一个问题。The ONE每次更新只能发送一个消息。这点是否合理?通常的理解是,发送数据包就像文件流一样,一直不断对往外发。
。。。反正 好麻烦 还是 要考虑到 就算 本次事件 假设 1 2 up 1 2 down 1 2 up 但是 有可能 1 3、2 3以前已经建立连接了3可能 有数据需要向1 2转发 或者1或2向3发了数据等着回复 但是 只激活了1 2 就有一个全局步调一致的问题 3要等到下次 有3 的事件或者 全部更新时 才轮到它不然 一直是 1 2
我是这么想的:对于连接事件,如1 CONN A B up,这个时候只需要更新A和B(A和B顺序随机)。对,有可能C要向A或B发送消息,这种情况就不管了,当然,如果C有消息到达A或B,就会轮到C发送(想想exchangeDeliverableMessage函数)。对于消息创建事件,如CREATE A (在节点A创建一个消息),此时,只更新节点A。
Pingback: The ONE使用笔记:目录 | Spark & Shine