科学网 › 标签 › 数据包

标签: 数据包

相关帖子	版块	作者	回复/查看	最后发表

没有相关内容

相关日志

放开户籍制度，并不一定利于国家的长期发展: yanghualei 2015-10-14 19:08; 如果放开东部省份的户籍管制，来一个人很快能够享受当地的教育，医疗以及（携带的养老金）养老等社会保障，我相信将有更多的年轻人涌向东部沿海省份，具有地缘优势的，特别是靠近东部的河北，河南，安徽以及江西、湖南以及广西等中部省份，因为人口迁移主要以年轻人为主体， 20-34 岁群体最多，区域发展不均衡，很多人为了改变命运，即使呆在大城市从事低端的服务业，也不愿意回去，所以中部省份短期将成为养老院（人少之后，只有发展农业才能提高人均收入，由于农业具有更大的外部性，收益一般较低），老人多了，处在产业链分工的低端，所以中部崛起将更加困难，这就是中部的后发劣势，东部的先发优势。东部放开户籍，实际是在吸取中部的人口红利，使得中部对东部进行人口补贴，使得中部在达到东部相同的老龄化水平时候，人均收入低于东部。感觉这样是牺牲西部和中部的利益，对西部和中部发展带来挤占，丧失国家的长期发展，当然还会造成人口过渡在东部膨胀，引致许多大城市问题：高房价，同时使得中部丧失寻找自己比较优势的机会，而是根据传统区域分工，被动的给您分配的产业。建议，对东部继续实行严格的户籍准入，实行有势差的户籍制度，引致只有少数人才能在东部沿海省份留下，大部分还回到户籍地，发展本地，寻找到真正适合本地的比较优势。一个地方，只有有人，才能有活力和发展起来，这样大城市和沿海才不会过渡拥挤，才能不会有高房价，中国经济才能遍地生花，当然也真正能够解决如今大城市所面临的问题，才能真正找到当地的比较优势。所谓的地域比较优势，并不一定是真的比较优势，为什么某些区域天生就处在产业链的低端，为什么美国就适合发展高端制造业和金融服务业，当然很多国家不服，有时候比较优势理论，是一种维持传统产业分工，传统秩序不变的一种理论说辞。只有采取严格的户籍的，才能堵住你，你才能回去，才能认真寻找当地的比较优势，才能挑战传统分工，才能真正实现当地的崛起。财贸经济原主编杨老师说，我们当前应该对中国建国以来经验的总结，进而上升到理论高度，这样才能真正发展一套符合中国理论，才能真正找到解决占世界五分子一人口大国的问题的方法，因为重要，才能真正获得国际经济同行的赞许，社会科学，不是自然科学，是建制的科学，必须符合本国的水土，才能盛开出艳丽的花。如建国，为什么要集中力量，大跃进，为什么要文化大革命，为什么要采取农业补贴工业，中西部支援东部，为什么实行双轨制，为什么利率管制，等等。如今主流都是全盘否定过去的历史。莫言拿诺尔奖，跟研究中国计划生育有关，我相信在计划生育上，中国只要进行理论总结，照样可以再开出诺贝尔的经济学花。有一个哥们补充一句：有时候需要实行差别公民，制造势差，才有动力什么叫中部空巢，就是东部户籍随便拿什么叫大国空巢，就是美国绿卡随便拿; 2734 次阅读|1 个评论

从方法论的角度读文章: gaooxinn 2014-11-19 16:09; 从方法论的角度读文章最近我完成了我的第一篇 infocom 论文精读，文章主要是研究车载网路由这一方向的。之前也读过一些国内作者的中文论文，与这些中文论文相比，牛文（ infocom ）最大的特点就是：文章的逻辑架构非常清晰！（清晰简明的逻辑架构反映了作者研究方法的正确），正如施一公教授所说：“学术期刊一般不会因为具体的语法错误拒绝一篇文章，但一定会因为逻辑混乱而拒绝一篇文章。”我想，文章逻辑 == 研究方法。这篇牛文的逻辑是非常清晰的，首先提出车联网能够具有多种优势功能的前提——数据包的稳定传输。接着，针对这个问题，结合当下车联网研究的现状，作者提出了两大技术难题： 1. 车辆轨迹的预测； 2. 目的节点位置变化给数据包传输造成的困难。这两大技术难题也恰恰是车联网研究领域的研究热点与技术瓶颈！针对问题 1 ，作者鲜明的提出了自己的创新点：以往的研究往往聚焦在预测单个节点的运动轨迹，而本文将视角放大到整个车流。单个车辆节点运动轨迹并没有很强的规律，但是站在整体的角度，同一地点车流量的大小具有明显的时变特点。在这个核心思想的基础上，作者对车联网进行数学建模，在苏州市 2013 年出租车运行轨迹这一历史数据基础上，通过数学方法计算出数据包从源节点到目的节点的期望延迟。从而将表征数据包是否能够稳定传输的关键参数定量表示出来。针对问题 2 ，作者并没有提出非常漂亮的创新点，只是使用了协议的思想，通过协议完成车辆之间的数据交互，从而完成了目的节点实时位置在全网的扩散。文章的特点： 1. 通过转换观察问题的角度，用创新性很强的方法解决了问题 1. 2. 文章在最后，将问题 1,2 通过一个 V2V 路由协议联系起来，并证明了该协议的正确性，分析了该协议的时间复杂度。从研究的角度，文章整个逻辑（研究方法）非常完备、完善、完整！自己的检讨（学方法论而非移植文章）：我在读这篇文章的时候，刚开始带着很强的功利心，我总想着通过读这篇文章，将这篇文章的具体方法移植到自己的项目中去，尽早写出自己的东西。现在来看，这种想法太幼稚、太虚伪了。虽然要学习这篇文章中知识性的东西（外在），但是，更要学习的是：作者的逻辑架构如何层层推进（也就是其研究是如何一步步展开），又是如何最终收拢在一个协议中，先发散再汇聚；作者如何提出问题，换个角度看问题，在转换角度后如何找到车流量具有时变特征这一关键点解决问题。可以这么说，逻辑架构是“内功”，具体的解决方法是“招式”。招式可以通过勤加练习迅速提高，但是内容是从开始练武就要养成的一种思维习惯！; 个人分类: 信息安全|3763 次阅读|0 个评论

[转载]NS2数据包结构解析(转): tangqiang1982 2013-7-21 10:47; 最近在做ns2的“反移植”工作，深入研究了一下NS2中包的结构，其定义主要在packet.h/cc中实现的，但是有许多代码是为了与TCL接口而设计的。其定义如下： class Packet : public Event { private: unsigned char* bits_; // header bits AppData* data_; // variable size buffer for 'data' .... }; 不得不说，上面两个字段域是Packet最重要的动动，其中bits_存储包头结构，而data_存储用户自定义的数据。但是，NS2其实是一个大而全的仿真平台，它在仿真时其实是将所有或者大多数数据包放在一个包里面，即使当前用不到。比如我们建立一个仿真环境，用来测试两个节点的通过TCP建立连接，然后发送数据，理论上这个仿真中只涉及到TCP/IP的基本存储功能，即应该包括hdr_mac, hdr_ll, hdr_ip, hdr_cmn, hdr_tcp，但是实际得到的包应该如下： hdr_ip hdr_ll hdr_cmn hdr_tcp hdr_XCP ........ data_ 那如何访问数据包中相应的子包呢，可以查看packet.h开始，发现定义了许多宏，如： #define HDR_CMN(p) (hdr_cmn::access(p)) #define HDR_ARP(p) (hdr_arp::access(p)) #define HDR_MAC(p) (hdr_mac::access(p)) #define HDR_MAC802_11(p) ((hdr_mac802_11 *)hdr_mac::access(p)) #define HDR_MAC_TDMA(p) ((hdr_mac_tdma *)hdr_mac::access(p)) #define HDR_SMAC(p) ((hdr_smac *)hdr_mac::access(p)) #define HDR_LL(p) (hdr_ll::access(p)) #define HDR_HDLC(p) ((hdr_hdlc *)hdr_ll::access(p)) #define HDR_IP(p) (hdr_ip::access(p)) #define HDR_RTP(p) (hdr_rtp::access(p)) #define HDR_TCP(p) (hdr_tcp::access(p)) #define HDR_SCTP(p) (hdr_sctp::access(p)) #define HDR_SR(p) (hdr_sr::access(p)) #define HDR_TFRC(p) (hdr_tfrc::access(p)) #define HDR_TORA(p) (hdr_tora::access(p)) 就是用来访问相应的字段，比如HDR_MAC(p)，即可以取得对应的域。而具体如何取则由hdr_***::access来实现。access是每一种包头都包含的，比如hdr_cmn: inline static hdr_cmn* access(const Packet* p) { return (hdr_cmn*) p-access(offset_); } 再看看包Packet的access函数，如下： inline unsigned char* access(int off) const { if (off 0) abort(); return (bits_ ); } 到此，基本明白了，offset其实是每个包相对于packet开始的偏移值，通过这个偏移值即可确定其在整个包中的地址。现在问题是，在哪个地方设置这个offset值，搜索了所有的C++代码也没看到对每个包的offset的初始化。经过仔细比较，发现在tcl/lib/ns-lib.tcl中的Simulator初始化init过程中有一个调用： $self create_packetformat 接着在ns-packet.tcl中找到了这个函数： Simulator instproc create_packetformat { } { PacketHeaderManager instvar tab_ set pm foreach cl { if { set off $cl offset $off } } $self set packetManager_ $pm } 应该是在这个地方实现了offset的初始化，换句话说，是在这个地方指定每个包的offset。设置断点并打印，证实了我的猜想： PacketHeader/PBC has offset 0 PacketHeader/LRWPAN has offset 8 PacketHeader/XCP has offset 216 PacketHeader/PGM has offset 272 PacketHeader/PGM_SPM has offset 288 PacketHeader/PGM_NAK has offset 296 PacketHeader/Pushback has offset 312 PacketHeader/NV has offset 320 PacketHeader/LDP has offset 328 PacketHeader/MPLS has offset 368 PacketHeader/rtProtoLS has offset 392 PacketHeader/Ping has offset 400 PacketHeader/TFRC has offset 424 PacketHeader/TFRC_ACK has offset 480 PacketHeader/Diffusion has offset 544 PacketHeader/RAP has offset 736 PacketHeader/AOMDV has offset 760 PacketHeader/AODV has offset 1568 PacketHeader/SR has offset 2376 PacketHeader/TORA has offset 3088 PacketHeader/IMEP has offset 3120 PacketHeader/ARP has offset 3632 PacketHeader/MIP has offset 3664 PacketHeader/IPinIP has offset 3696 PacketHeader/LL has offset 3704 PacketHeader/Mac has offset 3736 PacketHeader/Encap has offset 3776 PacketHeader/HttpInval has offset 3784 PacketHeader/SRMEXT has offset 3792 PacketHeader/SRM has offset 3800 PacketHeader/aSRM has offset 3816 PacketHeader/mcastCtrl has offset 3824 PacketHeader/CtrMcast has offset 3848 PacketHeader/rtProtoDV has offset 3864 PacketHeader/GAF has offset 3872 PacketHeader/Snoop has offset 3880 PacketHeader/SCTP has offset 3904 PacketHeader/TCPA has offset 3912 PacketHeader/TCP has offset 3928 PacketHeader/IVS has offset 4008 PacketHeader/RTP has offset 4040 PacketHeader/Message has offset 4056 PacketHeader/Resv has offset 4120 PacketHeader/QS has offset 4136 PacketHeader/UMP has offset 4152 PacketHeader/Src_rt has offset 4168 PacketHeader/IP has offset 4248 PacketHeader/Common has offset 4280 PacketHeader/Flags has offset 4384 实际上，每个包的offset应该为sizeof(hdr_***)。为了验证，写了一个程序测试。比如hdr_ip, typedef int32_t nsaddr_t; typedef int32_t nsmask_t; /* 32-bit addressing support */ struct ns_addr_t { int32_t addr_; int32_t port_; }; struct hdr_ip { /* common to IPv{4,6} */ ns_addr_t src_; ns_addr_t dst_; int ttl_; /* Monarch extn */ u_int16_t sport_; u_int16_t dport_; /* IPv6 */ int fid_; /* flow id */ int prio_; static int offset_; inline static int offset() { return offset_; } /* per-field member acces functions */ ns_addr_t src() { return (src_); } nsaddr_t saddr() { return (src_.addr_); } int32_t sport() { return src_.port_;} ns_addr_t dst() { return (dst_); } nsaddr_t daddr() { return (dst_.addr_); } int32_t dport() { return dst_.port_;} int ttl() { return (ttl_); } /* ipv6 fields */ int flowid() { return (fid_); } int prio() { return (prio_); } }; int main(int argc, char* argv[]) { printf("ip: %d\n", sizeof(hdr_ip)); printf("tora: %d\n", sizeof(hdr_tora)); getch(); return 0; } 程序的输出验证我的猜想。 packet.h的下面定义则实现了两者间的绑定： class PacketHeaderClass : public TclClass { protected: PacketHeaderClass(const char* classname, int hdrsize); virtual int method(int argc, const char*const* argv); void field_offset(const char* fieldname, int offset); inline void bind_offset(int* off) { offset_ = off; } inline void offset(int* off) {offset_= off;} int hdrlen_; // # of bytes for this header int* offset_; // offset for this header public: virtual void bind(); virtual void export_offsets(); TclObject* create(int argc, const char*const* argv); };; 个人分类: NS2|2111 次阅读|0 个评论

算法课上受到的启发: 热度 2 Rein 2011-3-30 09:02; 毕业半年，借复旦学报/复旦招生网的人气，也收到了差不多两位数本科低年级学弟学妹的咨询邮件，甚至高三小朋友的邮件。很多小朋友都在请教，怎么做研究，怎么发论文。其实这个问题我也在摸索，估计还只有一只脚入了门，另外一只脚还不知道该往哪儿踏。所以我建议小朋友问我不如去问老师……任何一个老师经验都比我丰富。不过，昨天上了一节网络算法课，对我的启发非常大。我自以为自己算法水平非常强的。虽然从没得过什么国际金牌，但是大部分日常问题一眼就能看出问题的复杂度和基本算法思路。不过，昨天那节算法课让我觉得，我的算法即使不说是白学了，远远没有学到算法思考的方法。昨天是第一课，讲算法设计的原则。老师先举了个问题，让大家来想该怎么做。一个路由器，希望能够对那些可能是“坏”的数据包进行标记，方便终端进行进一步的检查。一些安全专家统计了数据包中每个字符的频率，然后对每个字符给出了个阈值。如果一个数据包中该字符占的比例超过了这个阈值，那么就给这个数据进行标记。该算法用硬件实现。一个最简单的方法是每个字符一个一个计数器，每收到一个新的字符后计数器加1。数据包接收完整后再检查，是否有字符超过阈值。如果是的话进行标记。老师说，这个方法有个问题，收完了数据包后在从新扫描所有字符的计数器，复杂度就平白多了255。问大家有没有什么好的办法？（背景补充：硬件解决这个问题中，在收完整个数据包之前不知道数据包的长度。并且数据包长度的范围差距非常大）这个问题当然不难。作为有良好算法基础的计算机学生，很快能想到，每次计数器加1时，计算该计数器和阈值的比值的最大值，然后和一个全局最大值进行比较。最后只要这个全局最大值超过包长度就可以对该数据包进行标记了。不过我选的这门课不是CS的，是EE的。老师说，做除法代价太大了，我们不能做除法。于是我就半傻眼了（也许再思考下有其他算法，不过上课进度还是相当快的）。老师的做法让我大跌眼镜：老师说：这个问题定义的有问题。解决这个问题的方法是改变这个问题的定义。最重要的是解决正确的问题，其次才是正确地解决问题。这个问题的本质是对可疑的数据包进行标记，并且阈值也是人给的。与其使用和和包总长度的比例，不如使用和当前长度的比例，（需要特殊处理长度较小时的情况，取个max即可）。虽然解决的问题和原来不一样，但是最后效果其实没差。或者改进一下我刚刚的算法，与其可以除以一个任意的阈值，不如限制阈值的取值范围，使其可以用移位来实现，反正阈值都是人给的。通过改变问题，这个问题一下就简单而又容易地解决了。在国内，如果老师布置这么一道作业题，你去把人家题目给改了，自然是零分。不过做研究，第一步则需要能够分析出问题的本质，从而提炼出“正确”的问题去解决。有了第一步的找出问题，第二步就是找到所有可以利用的条件。拿TCP的拥塞控制举例。最早的TCP，利用的信息是丢包。即当数据包发生丢失时，肯定发生了拥塞，所以我们需要降低传输速率，降低的幅度为1/2。然而这个粒度实在是太粗了。进一步分析这个问题，知道丢包的原因是中间某路由器的缓冲区满了，所以才丢包。那么我们可以利用路由器的缓冲区的信息。现代很多路由器支持当队列长度在A到B之间时（A和B由路由器的控制者定义），对数据包进行标记。于是后来TCP利用的条件就是有数据包在路由器被标记，因为缓冲区增大超过了A，说明即将开始拥塞了，需要降低速率。SIGCOMM 10的一篇文章提出来的DCTCP。思想仍然是利用被路由器标记的数据包。不过，他利用了更多的条件，即统计了在一个窗口中被标记的数据包的数量（而不仅仅是有和没有)，所以可以更细粒度地进行拥塞控制。以前做作业，问题和条件都是老师给出来的，顶多仔细读题，不存在去寻找可以利用的条件这个问题。我觉得很多时候，由知识储备不充分，或者对最新动向不了解，比如不知道现在各种路由器的功能，所以找不到更多的可以利用的条件。所以我觉得，要做好这一步，需要大量平时的积累，而不是仅仅靠脑子想就出结果了。第三步就是把问题解决了。有了问题有了条件去解决问题，这一点在国内从小学就开始学了。所以我就不多说了。; 5799 次阅读|1 个评论

打开Aspen自带的数据包实例: wangshilei 2010-1-25 11:50; 步骤见下图： 1.启动AspenPlus后 2.查找收藏夹，看示意图 3.选择数据包 4.数据包图：; 个人分类: Aspen 软件学习系列|6680 次阅读|0 个评论

更多...

帐号		自动登录	找回密码
密码			注册

关闭 安全验证

标签: 数据包

相关帖子

相关日志

关闭安全验证