本文描述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