The ONE使用笔记:可直接使用的外部数据集

最近琢磨着如何处理MIT Reality数据集以导入The ONE,上午无意中发现已有人做了这部分工作,整理过来,以便交流(研究过程中发现,就数据集本身而言,就有很多可讨论的地方)。

1. 下载数据集

DTN的数据集通常在CRAWDAD下载(下载数据集,需要加入CRAWDAD社区,点这里。收到的邮件包含账号和密码可用于下载),但值得注意的是,上面的数据集有些是错误的,我就遇到这种情况,我在分析Bubble Rap论文中提到的数据集,发现结果与论文相差甚大,有的甚至连数据集描述都不一样,详情可参考之前博文《Bubble Rap数据集Infocom05, Hong-Kong, Cambrige, Infocom06, Reality》。得到Bubble Rap作者Pan HUI的确认,CRAWDAD上的Infocom06的确有问题。

CRAWDAD下载的数据集,几乎都要自己写脚本转换成符合The ONE的格式(StandardEventsReader format),关于如果转换格式以及如何使用外部数据集可参考之前博文《The ONE使用笔记:导入不含节点位置的数据集》。

2. 可直接使用的数据集

幸运的是,已有人分享了适合The ONE使用的数据集,见Matthew Orlinski的博文《Encounter traces for the ONE simulator》。以下摘抄其主要内容。

3. 分析数据集

事实上,就数据集处理上,还是有很多值得讨论的地方。比如Infocom06有50%以上的contacts,其开始时间和结束时间是一样的。这种情况下,是简单丢弃不管呢,还是按连接1秒来算。举例如下:

1 3 51293 51293 1 0
1 3 60603 60603 2 9310

除此之外,从数据集建模contact graph,计算节点的中心度,做社区检测,这些都离不开对数据集的处理。我在这方面做了一些工作,可参考之前博文《数据集Infocom06分析:求所有重叠区间(附源码)》。欢迎交流:sparkandshine@163.com

发表评论

电子邮件地址不会被公开。 必填项已用*标注

61 thoughts on “The ONE使用笔记:可直接使用的外部数据集

  • 2017年04月07日 星期五 at 08:10下午
    Permalink

    您好,请问您在用Cambridge和reality数据集时,有没有出现过转发消息个数为0 的情况。从最后出现的结果来看无论用那个算法start的消息个数就很少。

    Reply
    • 2017年04月07日 星期五 at 09:31下午
      Permalink

      没出现过relayed等于0的情况。另,这种数据集的pysical contacts真的很少,我仿真结果的各项指标也很低。

      Reply
      • 2017年04月08日 星期六 at 10:34上午
        Permalink

        感谢您的回复,我将TTL时间调大之后结果好一点。但是又出现了新的问题,就是在prophetv2算法中运行Cambridge数据集时到98436.6秒时,就停止运行了,没有报错也没有其他问题,之前在Bubblerap时也出现过这种情况,您知道是为什么吗?期待回到您的回复。

  • 2017年02月07日 星期二 at 08:41下午
    Permalink

    您好,我在网上找的数据集格式就是两节点在某时建立连接,但在节点路由的update中,会根据节点的通信距离建立连接,这两个不矛盾吗?

    Reply
    • 2017年02月08日 星期三 at 12:27上午
      Permalink

      你看的是哪个update?以及你用的是哪个mobility model?

      ONE支持的移动模型可以总结是两种,我估计你将两种混淆。

      (1)基于位置的数据集,如MapBasedMovement,节点在地图上移动,如果节点间在transmission range之内,那么就建立链接。
      (2)不含有位置的数据集(你说的第一种),两个节点链接“UP”,就建立连接,DOWN就断开链接。

      在一次仿真中,这两者有可能同时存在,取决于你的设置文件。就算是两种同时存在,但他们事件的处理方式是不一样的。

      Reply
      • 2017年02月08日 星期三 at 11:53上午
        Permalink

        您好,谢谢您的回答,我大概明白了。

        我看的是DTNhost中的接口update(),里面的.connect()。

        我是将model设为MapBasedMovement,但却导入的是外部数据集,这样的话模拟器按哪种方式模拟?我看了下report,好像还是按照外部数据集来走的,但是模拟的时候节点都在移动

  • 2016年06月13日 星期一 at 10:15下午
    Permalink

    我想问下,原始数据集中有没有包含产生的消息,中继或者转发的数据呢?哪里可以获取原始数据集

    Reply
    • 2016年06月13日 星期一 at 11:00下午
      Permalink

      Which trace do you mean? You can download traces from CRAWDAD as I mentioned in this article.

      Reply
  • 2016年03月05日 星期六 at 07:03下午
    Permalink

    请问只有gps的trace数据,能导入吗

    Reply
    • 2016年03月06日 星期日 at 09:35下午
      Permalink

      不管是什么样的数据集,只要转换成形如以下这样的,都可以:

      21574 CONN 1 40 up
      21687 CONN 1 40 down

      详情见:http://sparkandshine.net/en/the-one-use-notes-import-datasets-without-location/

      Reply
  • 2015年01月07日 星期三 at 05:41下午
    Permalink

    你好 CRAWDAD网站 已经改版了 好像美国的主服务器挂过一次原先 我记得上面有haggle项目的数据集比如比较经典的 infocom 06的现在都没有了 只有一个 infocom05剩下的和此博主列举的全部不同了话说 你有没有找到原始数据集 这个博主给的Cambridge Imotes和现在CRAWDAD上面的Cambridge不同了(网站上面貌似是haggle 1 2 3 这里列举的是3 4 6)

    Reply
    • 2015年01月07日 星期三 at 08:49下午
      Permalink

      您好。我访问CRAWDAD正常,博文的original dataset链接是旧的,新链接如下:http://crawdad.org/cambridge/haggle/infocom06你可以在这里下载:http://crawdad.org/~crawdad/download/cambridge/haggle/, Exp6.tar.gz数据集的确很恼火,当初对着Bubble Rap论文分析数据集,发现很多结果都不一样。后来得到Bubble Rap作者回复,crawdad的数据集确实有问题。他给了我infocom06。但其节点数只有78,我又懵了。多交流哈。

      Reply
      • 2015年01月07日 星期三 at 09:52下午
        Permalink

        恩 估计网站恢复之后 后台有些数据没有放上来 无语了。。。现在就显示了后台的3个。。还有infocom06大家一般把固定节点也算的 这样就是98个了 06那个大会 78个是携带设备的人 另外20个是不动的固定节点

      • 2015年01月07日 星期三 at 09:56下午
        Permalink

        数据集 也说明了“Participating nodes:- Nodes with ID#1 through #17 are static long range iMotes iMotes deployed throughout the area.- The three nodes with ID#18-#20 are long range iMotes that have been placed in lift of the hotel.- Nodes #21-#98 are participants of the Infocom student workshop.- Nodes with ID larger or equal than #100 are external devices.Note that the 20 stationary (long range) iMotes have more powerful battery and extended radio range (around 100 meters). The 78 mobile iMotes have a wireless range around 30 meters. ”

      • 2015年01月07日 星期三 at 11:33下午
        Permalink

        恩,这样的话,产生节点的消息范围(hosts)如何选择?这些数据集还有一个问题,节点相遇非常稀疏,如果bufferSize是infinite的话,仿真结果的性能变换并不大。

      • 2015年04月02日 星期四 at 06:35下午
        Permalink

        博主,小弟最近做了些仿真,仿真distributedBubbleRap协议,配置发现改变社区检测和中心度配置仿真结果无变化(完全一样),代码从github下载,socialnetwork的那个,感觉不对劲,另外消息大小设为1k?会不会太小?

      • 2015年04月02日 星期四 at 08:43下午
        Permalink

        您好。可否跟我分享下github的下载链接,我也想看看他是怎么做的。这个跟消息大小应该没关系吧,消息大小主要影响其他两个参数:(1)缓冲消息的数目,buffersize/msgsize(2)传输时间,message size/transmit speed 如果都比updateInterval小的话,那就不影响

      • 2015年04月07日 星期二 at 10:24上午
        Permalink

        他说的可能是这个https://github.com/zzqxztc/SocialNetwork-ONE-(里面 有代码 还有很多数据集)发现原作者不再更新已经删除了(?应该是github用的不是很熟)。好在发现网上有人备份了还有你上次分享的综述有很大帮助^ ^

      • 2015年04月07日 星期二 at 04:16下午
        Permalink

        谢谢告知。对了,你看完那篇有什么感想?我最大的感触是:几乎所有DTN router的研究集中在metric设计上。

      • 2015年04月08日 星期三 at 10:05上午
        Permalink

        恩 没错 社会属性最后都归结为 metric或者社区,不论怎么预测,最后传输时需要比较的还是效用值。就是相遇节点的metric比我好不好。。。另外 就是研究方法了 个人总结就是 先验 和 后验先验就是像文中讲的(Self-reported)提前 处理数据集 有离线关系 比如:线上社交关系,问卷调查等等。可以挖掘很多节点之间的现实共同兴趣点等等。而且网络关系稳定,便于处理。但是不特别符合实际,有时要借助集中式来发布信息,进行处理。而后验就是在是实际环境当中通过移动性推测社会属性特征。文中说的(Detected),偏向于分布式处理。不一定精确,但是最实际。bubblerap貌似是前面分析用的是先验。提前处理的网络社区关系。然后传输时固定。而实际上算法也可以支持后验。用作者说的分布式社区发现算法,github上的代码应该就是后者。

      • 2015年04月18日 星期六 at 07:22下午
        Permalink

        Hello again, 你知道怎么算一个网络的delivery probability的理论上限?举个简单例子,双向中继网络(A—R—B, A与B通过中继节点R交换消息),如果A、B每单位时间产生一个消息,那么delivery probability的理论上限是25%。试想,如果A、B产生消息速度分别是x, y/单位时间,那么这时候的delivery probability理论上限是?当网络更加复杂的时候,比如chain topology,该怎么算?有什么什么模型可以算这个的?谢谢。

      • 2015年04月21日 星期二 at 01:24下午
        Permalink

        你那个简单例子怎么算的?能详细说明下么 是每次一个单位时间 消息就转发到另外一个节点么?每二个单位时间片 A B都产生向对方的消息还是 只有其中一个产生?目的地是选择对方?我不太明白这里双向中继网络具体的工作形式,如果没有丢包,不是100%么。。。。好像现在大多数文献都不进行理论分析了,因为要是采用现实轨迹数据,无法数学描述文献好像都更关注自己是怎么构建的模型,怎么挖掘更精确影响力更大的节点,实验表明提高了成功率、延时或者其他。我自己看到的最近的一篇有分析的是 Jie Wu,Mingjun Xiao,Liusheng Huang. Homing spread: Community home-based multi-copy routing in mobile social networks. INFOCOM, 2013 Proceedings IEEE论文做出了理论分析,写的很复杂。没太深入看比如这篇 就没有分析理论结果,但是算法本身的机制写的非常复杂Feng Li, Jie Wu. LocalCom: A Community-based Epidemic Forwarding Scheme in Disruption-tolerant Networks. SECON ’09:Sensor, Mesh and Ad Hoc Communications and Networks, 6th Annual IEEE Communications Society Conference on, 2009.

      • 2015年04月21日 星期二 at 08:37下午
        Permalink

        双向中继网络(A–R–B),A与B通过R交换消息,有一些论文通篇只讨论这个网络The ONE设置文件:updateInterval = 1s, 视1s为单位时间,每隔1s,ARB各更新一次(我注释了updateHosts,咱们之前讨论过这点),值得注意的是:因为在无线,ARB一次只能一个节点做更新update。两个交叉流:A–>B, 1 messge / 1s,相当于每个单位时间,产生一个消息A<–B, 1 messge / 1s完成一次消息交换,需要4个time slot(理解为单位时间),但在这期间,产生了8个消息。那么:delevery_prob = (成功投递的消息:2个) / (创建的消息:8个)= 25%你觉得我这样算,有问题不?

      • 2015年04月21日 星期二 at 10:05下午
        Permalink

        我理解的是这样的初始A R B A(0) R(0) B(0) 已产生0 已接收0 delevery_prob:01 A R B A(1) R(0) B(1) 已产生2 已接收0 delevery_prob:02 A->R<-B A(1) R(2) B(1) 已产生4 已接收0 delevery_prob:03 A<-R->B A(1) R(2) B(1) 已产生6 已接收2 delevery_prob:2/64 A->R<-B A(1) R(2) B(1) 已产生8 已接收4 delevery_prob:4/85 A<-R->B A(1) R(2) B(1) 已产生10 已接收6 delevery_prob:6/10….最后 趋近100%你的意思是?A R B A(1) R(0) B(1) 已产生2 已接收0 delevery_prob:0A->R B A(1) R(1) B(2) 已产生4 已接收0 delevery_prob:0A R<-B A(2) R(2) B(2) 已产生6 已接收0 delevery_prob:0A<-R->B A(3) R(0) B(3) 已产生8 已接收2 delevery_prob:2/8这样 成功率确实最高是25%但是 感觉怪怪的啊 其实我们直觉上应该就是100%才对两个都没100% 是产生消息 和 接收消息 时间对不齐的原因R要分两次接收消息 而节点都是同时生成消息。。。

      • 2015年04月21日 星期二 at 10:12下午
        Permalink

        不可能是100%。你想哈,假设ARB是一样的节点,A–> R <–B,A与B以很快的速度向R持续地发送数据包,R是处理不过来的,如果TTL有限,必然会丢包drop,所以delivery probability不可能达到100%

      • 2015年04月21日 星期二 at 10:19下午
        Permalink

        A–R–B,考虑到无线的干扰,3个节点一次只能有一个节点占用信道,也不存在像处理器指令那样的流水线,所以在你的描述中:1 A R B A(1) R(0) B(1) 已产生2 已接收0 delevery_prob:02 A->R<-B A(1) R(2) B(1) 已产生4 已接收0 delevery_prob:0第二部不能这样,A和B不能同时向R发送数据,否则会有干扰,也叫隐藏终端问题。

      • 2015年04月22日 星期三 at 03:58下午
        Permalink

        我知道无线的冲突避免但是 有时候 可以 允许理论上的理想状态A和B虽然 是交替传输 但是 我们可以理想认为 其在一个时间单位完成了 而且R能处理过来那个25%的状态 感觉就是 时间间隙造成的要是 在实验状态里 指定一个很长的模拟时间AB节点都各产生100 个消息 然后结束成功率就能达到100%了虽然结果感觉很怪,但是你说的25%应该没什么问题

      • 2015年01月07日 星期三 at 10:09下午
        Permalink

        我看了你分析的那篇日志了是不是原作者 是按照78个移动节点分析的你分析的是98个所有的Bubble被引了了这么多次算是DTN里结合社会属性做的比较早的了,应该不会有太大问题吧。。。。。现在做这个最蛋疼的地方 一是数据集很麻烦二是 其实大家都用的one模拟器 太不友好了 用起来其实不顺手。。。

      • 2015年01月07日 星期三 at 11:40下午
        Permalink

        infocom06,98个节点,我是从刚才给你的网址下的http://crawdad.org/~crawdad/download/cambridge/haggle/, Exp6.tar.gz分析之后,发现有很多出入,包话readme,统计之后的数据。所以发邮件问的原作者,然后他给了我数据集,节点数目是78。我猜测,Bubble Rap用的是78个节点那个,因为DTN特性就是没有infrastructure,加之,作者主要考察的是利用社交网络的一些特性提升网络性能,所以只在78节点内,求node centrality, community.

      • 2015年01月08日 星期四 at 12:17上午
        Permalink

        恩 DTN其实也是可以有基础设施的(结合传统的无线网)DTN本身其实是一个又早(2001年出现) 又大的方向。。。我也接触不深 比较蛋疼。。。作者 不考虑固定节点 可能是因为只想考察 直接移动的社会属性节点。。。= =

      • 2015年01月08日 星期四 at 01:07上午
        Permalink

        PAN HUI给我的数据集是78个节点,但他的论文却是98个节点,很奇怪。可以比较确定的是:作者用78个节点来求节点中心度、社区检测。但不晓得是用78个还是98的数据集,即那20个固定节点是否参与通信,不得而知。

      • 2015年01月08日 星期四 at 01:21上午
        Permalink

        从论文来看,Bubble Rap将buffer设成infinite,就我过去的仿真经验来看,只要消息被复制转发机会越多,那么delivery probability就会越高,那么overhead ratio也随之越高。这样的仿真结果很没有说服力,除非delivery ratio提高了,但overhead ratio却降低了,那才有说服力。对了,论文的MCP(Multiple-Cope-multiple-hoP)是指在其他路由(比如MaxProp, Prophet)的基础上,限定消息的最多份数

      • 2015年01月08日 星期四 at 01:53上午
        Permalink

        嗯 delivery 和 overhead问题我也思考了 但是overhead对于one的模拟不能代表负载 可以翻译成开销 按照报告源码看是指 平均每一个成功被接收的数据包 需要额外多转发的中继次数 因为考虑到dtn环境下 每次连接建立机会是很宝贵的 下限是1 即wait 目的地出现 转发一次就到了但是 如果一个数据包找到了更快的路径 3跳到目的地 而差的算法等了了一条2跳才到目的地 但是反而也是前者的 overhead高 所以 我现在做实验都多考察一个延时 延时要是好 也有说服力 。。。以上个人看法

      • 2015年01月08日 星期四 at 05:51上午
        Permalink

        是的,我现在主要就关注3个指标:delivery prob, overhead, average latency. 你仿真的时候是怎么设定自变量的?我先在infinite buffer上测,旨在排除buffer size的影响,但每每测到的结果,不同协议的性能极其相近。还有另一个参数也一直困扰着我,消息产生的时间间隔,假设30s,host为[0, 77],这么说,同一个节点产生消息的间隔是30s*78。在这么长的范围内,updateInterval为0.1,完全有足够的机会交换节点间的信息。

      • 2015年01月08日 星期四 at 09:39上午
        Permalink

        我间隔不设这么小 1-2分钟 不然产生消息太密集了 one模拟太慢了 用的那个博主的infocom06处理过的数据集

      • 2015年01月08日 星期四 at 04:35下午
        Permalink

        是的,有时候得跑一个晚上。注释掉world.update函数的updateHosts,我觉得逻辑说得通,仿真速度会加快很多。即处理完所有事件,再update。while (this.nextQueueEventTime <= runUntil) { simClock.setTime(this.nextQueueEventTime); ExternalEvent ee = this.nextEventQueue.nextEvent(); ee.processEvent(this); updateHosts(); //注释掉 setNextEventQueue();}updateHosts();

      • 2015年01月08日 星期四 at 09:03下午
        Permalink

        这样做感觉有问题 读事件是一条条触发 one里changedconnection() 一般数据传输条件都是在这个函数里写然后正式转发 会在update()里面写你把updatehosts()注释掉了 意味着 每个节点update() 要在事件都读完了才会运行。。而且每个节点才更新了update一次

      • 2015年01月08日 星期四 at 09:41下午
        Permalink

        你说的没错。加上updateHosts,更像是节点只要有机会就往发送数据。不加updateHosts,假设updateInterval为0.5s,系统只有两种事件:CONN UP/DOWN 和 消息创建事件。连接事件相隔至少1s,假设有如下事件: A B UP C D UP E F UP一次性处理完,再update,实际上也几乎相当于每个节点一处理完事件就update。反观加上updateHosts,处理完A B UP,节点C,D,E,F也随之更新。另,我发现Reality数据集,没有节点24

      • 2015年01月08日 星期四 at 10:56下午
        Permalink

        哦 我又重新看了下源码 runUntil不是运行的最后时间。。。我当成是最后时间了 但是 正如模拟器说明的有个更新间隔 更新间隔约细 模拟约精确而且仔细看了下 其实你这样修改应该是使 更新间隔效果更好了 原来 更新间隔 设的非常大 但是 也会读一条 更新一遍 实际上更新也是相当频繁的(因为事件才代表连接建立 不然更新都是用处不大)这样看的话 注释掉 相当于 使更新粒度变大了但是假设 转发算法 当中有需要当前连接关系的转发 这样处理就会影响模拟精度或者 说每次转发 会消耗节点内存 而数据包 也是在模拟当中随机顺序产生的 产生时 和 每次转发复制的数据包 一起占用内存如果 限定固定内存量 然后再进行性能评估 会很影响精度但是 仔细想了下 只要本身更新间隔设的不是太大 这个也是影响不厉害的 不知道 你有没有对比注释前 和 注释后的输出。。我对时间较慢的处理 除了产生消息不密集外还有就是 发现 原来传输exchangeDeliverableMessages()、tryAllMessagesToAllConnections()等等自带的传输函数 在发送时 都会用getConnection()获得当前可得到的连接 然后遍历自己还有存在的message 进行发送 如果update更新频繁 这两次遍历非常影响速度所以 我是受其他算法源码 启发 想到实际上 每次节点只有相遇时 才产生新的连接 所以 只有up事件发生时 遍历一次自己的message然后 看看那个能向这个新的连接传输 产生《数据包,连接》组合 然后 对于每次只有新数据产生时 才需要将新的消息转发出去 所以 覆写creatnewmessage函数 每次新数据包产生时 为这个新数据包 遍历当前可以得到的连接 然后 产生《数据包,连接》组合而update则利用tryMessagesForConnected()处理这些组合也能节省很多时间

      • 2015年01月09日 星期五 at 12:34上午
        Permalink

        我没有很精确对比注释前后的结果,但就我仿真结果作图来看,走势是一样的。(我没有将其画在一个图)。。 除此之外,在没注释updateHosts情况下,updateInterval为0.1和5s,差别也不大。因为处理完事件就更新host。你的意思是处理事件之后,只更新必要的hosts?思路很好,不过你还需要考虑两点:(1)对于连接事件 CONN UP/DOWN假设A B UP,只更新A,B是不够的。因为其他节点,需要update才能继续转发消息。he ONE通过每个updateInterval内updateHosts来模拟,节点一有机会就发送消息。(2)对于新产生的消息假设节点A产生消息m,这个时候只需要看A是否有空闲信道(即邻居节点与A相连的connection都是可用的),然后选择一个邻居节点发送,即选择某个邻居节点作为下一跳。

      • 2015年01月09日 星期五 at 12:55上午
        Permalink

        有事件产生时 先生产的 数据 边组合 而转发还是在update() 里更新updatehost()依然正常更新更新其他的

      • 2015年01月19日 星期一 at 05:44下午
        Permalink

        @z的平方q 我得到一些新的仿真结果,但有悖于我的期望,期待你的看法。(1)我将传输改成广播,吞吐量relayed提升少许,但delivery_prob几乎没有提升The ONE的传输都是unicast,我将其改其广播(确切的说,是改为邻居节点可以overhear),如节点A给节点B发送一个消息,那么A的邻居节点同时也能收到该消息。我的预期是,吞吐量(总的成功转发消息数目relayed)会提升不少,因为现在每个transmision可以传输一个以上的消息。我在cambridge, infocom05, infocom06, reality都测了,也在不同协议都测,结果几乎类似。同理,我预期delivery_prob也会提升不少。(2)我在发送消息之前,假设轮到节点A作update,将this.getMessageCollection得到的消息做一些处理:将消息的目的节点是在A的邻居节点并且成功投递(isDeliveredMessage),这些消息直接删除。仿真结果显示,relayed提升约15%,但delivery_prob还是几乎没变。(3)总结relayed增加了,意味着消息传得更快了,意味着消息可以更快到达中继节点或者目的节点,延迟也就降低了。仿真结果显示,4个数据集的relayed皆约提升15%,但只有infocom06的延迟降低了(我猜原因是我用了98个节点,即将固定的20个节点也算上去,这样网络更加密集dense),其他的几乎没什么变化。==>或许可以这么解释,relayed针对的是网络所有的包,而latency只针对成功传递的包。再说到delivery_prob,4个数据集几乎都没有什么变化。我在想,是不是delivery_prob在某个TTL下,已经达到上限了?接下来,我打算去分析下数据集的delivery_prob上限。有没有可能调整一些参数,让delivery_prob区别明显起来??PS:我的buffer设成infinite,考察TTL变化对relayed, delivery_prob, latency_avg, overhead_ratio的影响。

      • 2015年01月19日 星期一 at 07:07下午
        Permalink

        1.“如节点A给节点B发送一个消息,那么A的邻居节点同时也能收到该消息。”设定为消息不经过A转发,直接到达么?2.”relayed针对的是网络所有的包,而latency只针对成功传递的包。”这点是对的。你仔细看下report文件夹下的MessageStatsReport源码就知道了3.“4个数据集的relayed皆约提升15%,但只有infocom06的延迟降低了” 这个可能是因为 更多的成功接收包,拉低了延时吧。MessageStatsReport只计算发送成功的数据包延时4.“有没有可能调整一些参数,让delivery_prob区别明显起来??”具体我也不太了解。主要就是设定不同的 TTL吧。还有主要影响在于转发算法。另外,TTL要设的间隔大一点,几分钟 几小时 几天 差异就能看出来了

      • 2015年01月19日 星期一 at 08:16下午
        Permalink

        感谢回复。不是的,还是经过A转发,假设A有邻居节点{B, C, D, E},按之前的算法,在一次update中,A只能向{B, C, D, E}其中一个发。我现在将其改成广播,也就是说,A发消息m给B,其他邻居节点{C, D, E}也能overhear到消息m。我TTL设成[2min, 10min, 1hour, 3h, 6h, 1day],TTL再长,一个晚上很难跑完。

      • 2015年01月19日 星期一 at 08:34下午
        Permalink

        这个间隔够了那么差异小 就是转发本身的影响了

      • 2015年01月19日 星期一 at 09:17下午
        Permalink

        对于Epidemic + infinite buffer,delivery_prob应该是所有Router的上限吧?这种情况下,delivery probability差异就很小。我想到的两种可能:(1)数据集的形成的网络是spase的,统计router作update时的getConnections.size,除去size为0,有近一半的size为1(即只有一个邻居节点),这种情况下,overhear与否压根没有影响。(这点我已验证)(2)因为数据集是spase,对于有限的TTL,delivery_prob可能有一个上限,而且我猜这个值不会太高。(正在验证)对了,你产生消息的方式是全网产生吗?即设置文件的hosts和tohosts都是[0, N-1]?

      • 2015年01月19日 星期一 at 09:24下午
        Permalink

        上限的话用Epidemic 可以知道每个数据集的 delivery_prob和latency我设定数据也是 全部随机的

      • 2015年01月23日 星期五 at 06:17下午
        Permalink

        Hi, 请问有知道的简单DTN场景吗,比如像two-way relay networks(只可惜连接不是动态的),我导师让我把算法先找个简单的DTN场景测试,您有什么建议吗?

      • 2015年01月23日 星期五 at 09:02下午
        Permalink

        恩 好像可以按照one仿真器的说明 自己设定几个动态的点而且可以根据制作的地图场景自己移动 记得好像 看到过 有不同的移动模型 什么日间活动移动我目前也只是会外部数据集的导入 其他方式没有研究。。。个人感觉 简单的场景 就是自己设定几个点 然后 在一张地图上移动

      • 2015年01月23日 星期五 at 09:09下午
        Permalink

        谢谢回复。我之前为了排除数据集变量的影响,用randway movement测过,但结果delivery_prob实在太低了,记得不是0.15。

      • 2015年02月05日 星期四 at 09:42下午
        Permalink

        你好。在无线双向中继网络A–R–B,A与B能同时向R发消息?我的理解是不能,因为R接收到两个重叠的信号,没法还原。我理解对吗?

      • 2015年02月05日 星期四 at 09:55下午
        Permalink

        不知道 现实当中和协议有关吧。。。记得以前计算机网络课讲过 那个802.11 有冲突避免重叠信号 接收之后 可能会有问题还有 对了one有关的资料 在github上面有不少我搜索bubblerap 关键词发现的

      • 2015年02月05日 星期四 at 10:11下午
        Permalink

        我刚才看了The ONE的源码(checkReceiving会返回TRY_LATER_BUSY),The ONE是不允许的。解决了隐藏终端问题。GitHub,还真的是,谢谢分享。

      • 2015年01月08日 星期四 at 02:22上午
        Permalink

        MCP是作者自己设计用来对比的相当于传染病路由的弱化版本 限制了传输的每一个数据包副本数 和 跳数 个人认为和 spray and wait比较像 但是 从论文描述 bubble应该也是复制型的?不是单一副本传输?

      • 2015年01月08日 星期四 at 05:37上午
        Permalink

        是复制型,我所看The ONE的router源代码,只有DirectDelivery是单一副本传输。FirstContact,我没读源码。

      • 2015年01月08日 星期四 at 09:33上午
        Permalink

        firstContact也是但一副本 思想朴素 每次节点只向第一个相遇的节点传输数据包

      • 2015年01月19日 星期一 at 08:37下午
        Permalink

        可以发一份数据集到我邮箱吗?795646945@qq.com 谢谢

      • 2015年01月19日 星期一 at 10:20下午
        Permalink

        很抱歉,刚才看多说后台数据,才发现你的评论被自动视为垃圾处理。至于数据集,我直接在这里下载的:http://www.shigs.co.uk/index.php?page=traces

      • 2015年01月07日 星期三 at 11:54下午
        Permalink

        关于仿真器。我最早用的是ns3,但ns3不能导入不含位置节点的数据集,这意味着需要自己写个移动模型,没思路。后面转到The ONE,的确有些恼火,不得不阅读大量代码。