又是纷繁絮绕的一个秋,我很遗憾有些事情我做的处置的确实欠妥亦或是缺乏了些许于年龄不相关的东西吧。天天2B一样的活着,突然一个耳光打来,确实有些冷静了!冷笑道:也许确实是有些什么吧!
迷茫和梦想充斥着脑海中。我应该慢下来,慢慢的审视自己,听取别人的意见,规规矩矩的!可是谁又理解其中的甘苦呢?犹如一颗长在岩石夹缝中小树,必定要委屈求全的,梦想很远很远,我很庆幸我一直在走,虽然有时候走的很难很慢,却一直没有停下脚步,可能梦想永远都不会实现,即使实现不了,也无什么可悲哀的--命!
最近又重写TCP部分APP程序,其中发现几处问题第一处是网卡的吞吐量和应用程序所能达到的最高效率处理率的冲突问题,这个问题毫无疑问在网络空闲时数据输入进来,中断繁忙的进出,BUF频繁的分配释放,由于使用了堆内存,所以效率比构建的结构内存要快,然后输入协议栈,那么这样下来协议栈要处理的包就远远的超过了CPU时间片给他的时间导致了数据的挤压,以至于有些响应出问题,重发和转发包的问题。这里应该加一层过滤,不属于自己的统统丢掉。有的硬件有数据过滤,有的没有需要软件构成。这样可以大大的屏蔽不需要的报文处理上,减少CPU负担。这是提速A+第二处是网卡驱动问题,首先你应该有一个很稳定的网卡驱动,也就是要在抛去协议栈的时候测试那段DEV代码,看中断收发,收发可以构建一些简单的包,比如ARP,和广播包等!这是B+。再者就是TCP的SYN信号处理,这信号对程序员来说陌生!那是因为没看TCPIP协议,SYN发送始于socket 的connect host ip ,然后由于TCP的控制块控制状态变为SYNSEND,此时可能链接不成功,不在线或者故障阻塞等,不要试图关闭,等待TCP SEND SYN ==MAXSYN,这个间隔在1左右,或者更短一些,发送完毕之后host还是不在,则关闭链接,这时候上层关闭端口才是正确的!!!这里处理不好也是要命的!现象时bind端口不成功,表面上看是绑定的不成功其实深层的原因是过早的关闭了控制块,殊不知协议栈并不会按照你的意愿去做,因为你违背了他的意愿,他还有任务没有完成呢,所以他会挂起这个继续等待,这个等待就长了,于是乎你在建立一个则增加一堆内存,在一次往复,最终内存爆掉或者协议栈用完他的堆。再也不能工作为止!GAME OVER!
彼采葛兮,一日不见,如三月兮!
彼采萧兮,一日不见,如三秋兮!
彼采艾兮!一日不见,如三岁兮!
比特
|