goto和setjmp,longjmp的理解
首先搞清楚goto的作用范围。
goto的作用范围仅仅在一个函数内，跨越函数是不行的。
setjmp和longjmp组成一个对。用来达成goto的作用，但作用域比较大。
setjmp有点像label。执行他之后，会在该代码段记录下指令地址。
longjmp和goto类似，用于跳转用。
您当前位置: 首页 »
思考
分类目录归档: 思考 - 第6页
网卡端口一下up一下down的分析
今天又遇到“拔网线”的问题。起初以为真是“拔网线”，但为了尽快分析结果。我立即就找到了房东，走到交换机那看到，link灯是一下up一下down。
怀疑是交换机或者线路问题。笔记本和一根线同时拿到现场测试。发现无论换到交换机还是路由器都是老样子。 而之前确定带去的线是正常的（外环连通）。
回忆上次的问题，发现后来是因为我把电脑关掉又重新开机过。这次通过关机再开机，发现网卡正常了。询问房东电源是否接地， 答案是未接。
自我认知的重要性
其实一直被人忽视的一个重要东西。自我认知！自我认知也在很大一定程度上决定了一个人的发展。我出生于80后，下面是我对自我认知的一点点认识而已。
在生活的接触当中，遇到最多的就是，自我认知性差的人。
兄弟间有 ，同事也有。我不敢说我的自我认知性有多么的好。但我对自己的自我认知能力还算自信。
很多人心思比较粗大，有些人心思比较细致。但这都不影响自我认知的水平。
但如果自身能够稍微注意，心思加强细致化发展，这倒可以弥补一些认知上的不足。
流量整形和数据包时间片的一些认识
为什么会在深更半夜来提及这个问题？
因为在校时的网络流量一直让我非常在意。学校的组网我并不了解，当时没有往网络方向靠拢，更就不太可能研究这些了。
记得当时学校的网络实际联网大概我还是偶然见过一次。在接入层，学校用了tplink的24/48口的便宜交换机。交换机的上行方向与一个快速的G级交换机连接，这样就完成了一个很小片区 的布局了。这个快速G级交换机又与一台汇聚层交换机连接。连接方式好像是光缆。条数不明，应该不会很多的。因为学校就屁大一点。
汇聚一类的交换机，学校好像也就有2台。这样就走到了一台路由那，这台路由估计应该用了核心层中最便宜的。因为汇聚层本来就是作为快速交换用的，只有核心层才是用来做路由协议的。
下面进入正题。
对i2c的认识
一开始看到公司做驱动的那些家伙拿着i2c jtag来看一些寄存器之类的东西。
今天查了一下，看到i2c是作为总线接入使用。通过查询发现，i2c可以下挂多个串行总线，目的是用来替代桥或者仲裁；低速和高速设备之间的中间媒介。
通过这样的结构有2个好处：
1，解决了高低速设备之间交换数据的问题。让高速设备不需要等待低速的响应，而直接转为执行其他请求或者指令。
2，扩展了地址线。单地址复用功能。对i2c发送指令进行不同片选，可以让一个地址具备片 选更多设备。
出租屋这边有人老搞小动作有意思嘛？
先说一说我租房的地方 滨江区来家里，在我联系到房东家咨询房子的时候。房东他老婆就在电话里给我打招呼了：“平时网络可能卡一些，如果网络卡，可别太有意见啊？”
其实听到这句话的时候我就比较的奇怪了，来到房东家看了房子之后，还不错价格也高了一些。但看着房东好像很老实的样子，我也就没有太多的怀疑。加上房东也是本地人（口音听得出来），觉得杭州人还是挺好打交道的。
入住当初不慎了解到了房东家的路由和pppoe帐号密码。因为路由器是tplink低端货，不支持qos。我家也刚好有一个这样的路由，记得通过升级某个版本的软件，就有qos。
后来一直努力查找，终于找到了一个软件版本支持qos的。升级之后为了避免房东发现，我于是将密码改掉。估计房东也知道我改掉密码了，不过他并不知道他家的路由已经支持限速功能了。
入住这么几个月里，一直用路由器的限速功能做测试。统计全网中下载最狠的（包括用一些p2p协议看电影），前提是我通过mac和ip绑定。这样的结果就是每次dhcp到的ip是固定的除非用户自己设定一个合法的ip。
关于TCP中窗大小与带宽延时积的、阻塞窗口认识
这需要从tcp慢启动开始说，慢启动的意图在于让网络通道处理理想状态下。理想状态：发送方发送的间隔=网络中刚好不重传的情况（理想不丢包）。
假设tcp窗无穷大。那么就有这么一个局面，网络中暂时储存着一些数据包（由于延时造成）。这时计算得到的结果是带宽延时积= ping延时 * 网络速率（这个速率是TCP协议速率= 理论速率 – (帧头+尾)） / 8 (现在的单位是byte,除于8就是将bit换成byte)
设想2个队列，一个是由于网络暂存特定抽象的，另一个是TCP窗。
关于winpcap中数据包捕捉相关（u_char *pkt_data）
初学winpcap, 看着例子过来的。winpcap的文档还是有些简单；大多都是列出了函数列表，让用户去看。对于我这类E文差到极点的人来说，还是吃力。
好在还有一个中文的理解解说。这个u_char *pkt_data在很多运用中都应该能用到，他是一个内存buff的指针，指向抓到的数据包（也有可能是解析过的数据包）。
1，在关于流量统计的一文中，这个pkt_data的数据结构被winpcap自己格式化，因此出现了自有的格式。
2，在过滤器抓取数据包一文中，这个kt_data指向的数据又是从osi第一层封装中取出来的数据。
因此，在不同的情况下。pkt_data将会有多种数据结构。
寻找到了新的目标和方向
以前太过于片面的理解嵌入式了，所以了解到arm之初就开始学起了arm。那时候要补的知识太多了，同时又是学生时期，迷茫也没有人带；再加上寝室作息有问题，导致曾一度放弃。其实回头想一想，arm也许会比也么高不可攀，学习不得要领；基础知识也不够用，有问题那是当然的。
现在arm的人越来越多，其实我还是很羡慕他们做arm的人。但可惜的是，由于google（java-linux）操作系统的推出，让我非常的失望。几乎手机嵌入式又要回归到java上，我并不排斥java。但java程序员中太烂的人太多了，不像C/C++一样具有选择性。只有强者才能做到核心的部分。
小霸王年纪大了，网卡受不起浪涌了
今天房东去复位交换机和路由器。其实也该是复位的时候了，天气又热；又有在线看电影的。后来我就设置了一下路由的限速，一不小心，路由就出现处理数据包来不及的情况。也不知道是cpu忙，还是缓冲满了。
复位的时候，房东可能操作不当，造成我这边出现了3-4次网卡up 和 down。没想到，就这么一下子，网卡就假死了。表现为，网卡不转发数据，也不接受数据。当是否down网卡芯片还是有反应。
这样的情况，我记得以前出现过。次数不算多，这次出现的特别严重。主板芯片组是sis的，网卡也是。后来我自己用拔插网线的方式复现了一次，基本断定是网卡部分的问题。
防浪涌应该改是每一个网卡都应该做好的，现在的笔记本越来越白菜价。看来背后是这样的偷工减料，要怎么说都不知道了。
半开连接数与家用路由丢包问题
首先说一下标题中提到2者之间的联系。半开连接是针对TCP协议来说，而且这种做法是普遍运用于BT,电驴用。
因为半开连接对于谁来说都是一种高效的做法。
先说一说路由器丢包的问题。
今天在BT下载时，偶然发现路由的log上有这么一些信息:
Free=866, Busy=158, Bind=154, Inv=0/1, Bc=0/0, Dns=109, cl=48, fc=0/0, sq=2/30
Free在路由初始化时，被设置成了1024，bind=0.其他的几个也没怎么看明白，Dns应该是dns请求数吧，cl可能是换行符？或者别的。sq可能是arp请求？bind难道和端口映射有关？
而free的初值，我想就应该是路由器的转发缓冲了。至于有多大？不知道，只知道有1k的缓冲项能力。当我把bt打开时，busy可以达到1000+，可见BT在寻找节点初的请求量，当若干分钟后busy会稳到200左右。后来我又打开电驴，初始化之初，free只有600。之后逐步递减到400左右。
路由丢包，原因已经很清楚。就是缓冲溢出，转发能力造成的。如果局域网内有多个高网络并发网络程序，那么很有可能会造成网络堵塞。这与adsl上行拥堵造成的网络不畅通有相似之处，也有差别。
同时，我也佩服这BT客户端，居然能在初始化之初并发这么大。相对电驴还是温和一些。
回过头来说半开连接，他是TCP四次握手（断开连接）的一种特例。正常情况下，如果四次握手行为中，只有2次握手出现，那么有一方很有实用了半开连接。
一个很明显的案例就是C/S中，服务器listen，然后accpet，在established后，客户端即将断开连接。此时会出现TCP的四次握手。但为什么四次握手之后，服务器依然还能接受本socket的TCP连接呢？
因为服务器就是用了类似半开连接的做法。在给予客户端FIN确认时。自己虽然关闭掉了一个worker线程，但并没有关闭自己的实际连接。因此它能够继续listen , accpet下去。
至于其他更多的内容，还需要我进一步的学习才会清楚。
正在离现实不远的地方进发着
星期五的时候，工头（PL）过来说，某思的C#小组要过来10个人。然后呢就说腾位置给他们的事情，说着说着就想起那个梦。
最后工头们最后商量着吧，就把某思的位置定在了会议室。于是乎一个下午大家就都忙活起来，回到住处。一直在反思这自己，难道会有这么巧的事情？于是想到，就记下来吧。用blog将每一次的巧合记下来。看一看到底是不是真有其事不就知道了？呵呵。
TP-link路由器也会丢包？还是堆栈溢出？
我家有一个tplink的r402m，房东家也是这个。测试的都是用我的笔记本，只不过防火墙换了一下。
特点如下，在我的笔记本上同时开电驴和BT以后，会发现网络阻塞。就连路由的web管理页面都很难打开。
当我关掉其中一个以后，情况会有一些好转，当我都关了以后，路由需要一定时间才会稳定到初始状态。甚至有些时候路由都会出现转发数据包困难。
手头因为没有这个路由的原理图一类的玩意，也很难去判断，到底是以太口的缓存溢出，还是ARM遇忙。
关于dns的方向解析的辨析
刚刚看到tcp/ip的dns部分，之前并不了解方向解析的真实作用。看到这部分之后，回想起几年前的BT伪造数据包攻击事件，我才想起来。
先回顾一下几年前针对p2p的攻击，攻击都很清晰，大都是在p2p网络里面伪造数据包。伪造的数据包也连通报头也一起伪造，因此ip和mac基本都是假的。后来在BT下载器里面，就有人用到了免费代理ip的做法。
我记得好像是在BT网里面选择几台知名的服务器做代理ip，他们的数据包都通过这些代理服务器转发认证。也就是说，在BT链接初期，节点直接的链接是靠代理服务器来中间媒介完成的，同时代理服务器中也会同时记录下客户ip。而被请求端则使用方向解析的方法来认证ip地址的合法性。至于具体细节我已经模糊了，由于关键字的淡忘，现在已经很难找到当时的文章。
方向解析的实质，就是将ip地址翻译成域名。可以看作域名解析的逆过程。但不可等同，因为配置未必就是ip和域名一一对应关系。
在这里又多出一种解决问题的办法，在很多的确都有运营商dns劫持的情况。如果采用dns方向解析，其实很能说明问题。因为有些地区的劫持相对隐蔽一些，在http会话里面做过手脚。
IE opear orca初步尝试
是在受不了IE内核了，终于打算换一个。
首先说一下我的环境吧，winxp sp2 64bit，听说这个版本是基于win 2003 server 64bit修改过来的。说实在的，这个xp 64bit的确有很多一些隐性的性能特性，要比32bit好很多。但不知为什么，居然昙花一现。。。估计这是MS的有意的吧？
我用的是ie 8 64bit版本。硬件是t1400的u， 2g 的 内存。
因为平时都很干净，除了flash控件以外，也没有太多别的玩意。因此也很少遇到ie8莫名其妙假死的情况。正因为如此，我一直感觉ie8已经够我用了。
但一些很头疼的问题也不是没有，比如说遇到一些网页的时候。cpu占有会出现很大的抖动，而有一些时候100%的占有时间又比较长。不过最终都会逐步回落到正常水平。打开IE速度也是个问题，打开网页同样也是个问题。瞬间的假死，会让人错觉认为是网络慢造成。