本文深入解析nam和xgraph在数据传输拓扑构建中的使用方法，包括nam如何转换test_xgraph.tcl文件，xgraph的比率解释，以及如何识别和处理重复包等问题。同时，通过对比广播和aloha两种设置下的拓扑效果，探讨数据传输过程中的丢包原因及解决方案。
搞清楚nam和xgraph是怎么用的。
一、nam
可以将test_xgraph.tcl改成nam的拓扑。
二、xgraph
the ratio of the number of packets successfully received by the sink to the number of packets generated by the source
动态的不行，就先研究静止的就行了。
为什么hastPtr != NULL，就说明了是重复包。
node2在判断isCloseEnough时被淘汰。
我就纳闷了，为嘛调试时还是会出现当时设定的15和-15这种对称情况？
prj的值竟然为129.28，导致不close了。
我的直觉怎么这么准？就是
set opt(x) 1000 ;# X dimension of the topography
set opt(y) 10 ;# Y dimension of the topography
set opt(z) 10
的问题，这回影响就算投影值。
将broadcast和aloha两种设置拓扑相同，然后比较成功率。
为啥连最简单的broadcast都会出现这种情况？发送20，却只能接收10个包，为什么会丢包？
好吧，最起码uw_aloha可以用了。
探讨下丢包的原因。。。
SINK 5 : terminates (send 20, recv 0, cum_delay 0.000000)
SINK 0 : terminates (send 0, recv 10, cum_delay 31.499945)
SINK(0) : send_id = 5, num_recv = 10
在vbf中：
vbf_neighborhood *hashPtr= PktTable.GetHash(vbh->sender_id, vbh->pk_num);
通过判断hashPtr是否为空，这里的主要作用是过滤掉回传的包（here.id > forward.id，正常情况下here.id < forward.id）
因为之前改的代码，导致num_send被加了两遍，这个问题得以解决，接下来还是试一下ACK吧。
并没有从5传到4，也就是说你必须按照uw_aloha的规则。node4在醒来时转发了，但是为啥node 3没有下文了？
原来是1_aloha.tcl中方向设置反了，矫正后可以进行传输并且成功率也是100%。
接下来要做的就是在确定转发包之后，要发送ACK。
MACPrepare做了哪些事情：组装数据包；
MACSend中仅仅做了个调度：tcl脚本中用了LLType，并且Type就是LL。
LL set mindelay_ 50us
LL set delay_ 25us
LL set bandwidth_ 0
LinkLayer？
Scheduler::instance().schedule(ll, pkt, delay);ll是什么，如何处理的？
本质上LL，仅仅是一个abstract，而实体则是UWALOHA、Broadcast等MAC协议。
关键是调度哪个函数来接收呢？光调度，没说最后调用哪个。
1、MacSend是突破点，还是没找出到底在哪调用。
2、受影响的节点肯定要计算的，但是要在转发时进行选择。
3、接收节点接收到数据包后要进行ACK，节点如何回复ACK。
照理说，发送完之后应该设置一个ACK等待时间啊。
MACSend(Packet *pkt, Time delay)，其中delay是0，因此毫无延迟立即转发。
通过每个都设置断点，立即进入的函数是UWALOHA::TxProcess函数。
MacClassifier：
包复制昂贵，如果设置MacClassifier::bcast_为一个非零数，会导致MacClassifier一直在复制包。
Mac shared medium enviroment：wireless and local area networks，mac object 添加mac header，传输包给信道层，接收端mac object从physical layer分类器异步地接收包，mac层处理后将数据包传递给链路层。
LL(link-layer) Class
RECV其实就是接收数据包的过程包括Data包和ACK包。
hdr_UWALOHA* UWALOHAh = hdr_UWALOHA::access(pkt);
用于从pkt中提取包头
在VBF中怎么发送数据包的就可以怎么做ACK包，而创建包的工作在uwsink中已经做了，可以借鉴，其实最简单的方法就是将原来的数据包复制一下，然后添加hdr_UWALOHA。
(1)uwsink.cc中创建包的内容：
一、nam
可以将test_xgraph.tcl改成nam的拓扑。
二、xgraph
the ratio of the number of packets successfully received by the sink to the number of packets generated by the source
动态的不行，就先研究静止的就行了。
为什么hastPtr != NULL，就说明了是重复包。
node2在判断isCloseEnough时被淘汰。
我就纳闷了，为嘛调试时还是会出现当时设定的15和-15这种对称情况？
prj的值竟然为129.28，导致不close了。
我的直觉怎么这么准？就是
set opt(x) 1000 ;# X dimension of the topography
set opt(y) 10 ;# Y dimension of the topography
set opt(z) 10
的问题，这回影响就算投影值。
将broadcast和aloha两种设置拓扑相同，然后比较成功率。
为啥连最简单的broadcast都会出现这种情况？发送20，却只能接收10个包，为什么会丢包？
好吧，最起码uw_aloha可以用了。
探讨下丢包的原因。。。
SINK 5 : terminates (send 20, recv 0, cum_delay 0.000000)
SINK 0 : terminates (send 0, recv 10, cum_delay 31.499945)
SINK(0) : send_id = 5, num_recv = 10
在vbf中：
vbf_neighborhood *hashPtr= PktTable.GetHash(vbh->sender_id, vbh->pk_num);
通过判断hashPtr是否为空，这里的主要作用是过滤掉回传的包（here.id > forward.id，正常情况下here.id < forward.id）
因为之前改的代码，导致num_send被加了两遍，这个问题得以解决，接下来还是试一下ACK吧。
并没有从5传到4，也就是说你必须按照uw_aloha的规则。node4在醒来时转发了，但是为啥node 3没有下文了？
原来是1_aloha.tcl中方向设置反了，矫正后可以进行传输并且成功率也是100%。
接下来要做的就是在确定转发包之后，要发送ACK。
MACPrepare做了哪些事情：组装数据包；
MACSend中仅仅做了个调度：tcl脚本中用了LLType，并且Type就是LL。
LL set mindelay_ 50us
LL set delay_ 25us
LL set bandwidth_ 0
LinkLayer？
Scheduler::instance().schedule(ll, pkt, delay);ll是什么，如何处理的？
本质上LL，仅仅是一个abstract，而实体则是UWALOHA、Broadcast等MAC协议。
关键是调度哪个函数来接收呢？光调度，没说最后调用哪个。
1、MacSend是突破点，还是没找出到底在哪调用。
2、受影响的节点肯定要计算的，但是要在转发时进行选择。
3、接收节点接收到数据包后要进行ACK，节点如何回复ACK。
照理说，发送完之后应该设置一个ACK等待时间啊。
MACSend(Packet *pkt, Time delay)，其中delay是0，因此毫无延迟立即转发。
通过每个都设置断点，立即进入的函数是UWALOHA::TxProcess函数。
MacClassifier：
包复制昂贵，如果设置MacClassifier::bcast_为一个非零数，会导致MacClassifier一直在复制包。
Mac shared medium enviroment：wireless and local area networks，mac object 添加mac header，传输包给信道层，接收端mac object从physical layer分类器异步地接收包，mac层处理后将数据包传递给链路层。
LL(link-layer) Class
RECV其实就是接收数据包的过程包括Data包和ACK包。
hdr_UWALOHA* UWALOHAh = hdr_UWALOHA::access(pkt);
用于从pkt中提取包头
在VBF中怎么发送数据包的就可以怎么做ACK包，而创建包的工作在uwsink中已经做了，可以借鉴，其实最简单的方法就是将原来的数据包复制一下，然后添加hdr_UWALOHA。
(1)uwsink.cc中创建包的内容：
扫一扫
2688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
