Etrnls’ Blog

很多人还是对这个东西存在误解，认为XP及以后的Windows系统限制了并发TCP连接数。

首先，2000以后的Windows系统中，确实有对并发TCP连接数的限制的功能，不过这个限制值是可能的最大值0xFFFFFE。
那么所谓的“XP限制连接数不超过10”是什么意思呢？这里的限制是“半开连接数”，简单的说就是从开始连接到连接成功（或者失败）中间过程的连接的限制，比如同时并发进行了1000个连接，那么这时只有10个连接在进行，其他的在排队，等这10个连接中某个连接成功建立后从排队的里面取一个开始初始化，最终所有连接都会进行。所以这里没有连接数限制。

既然这样，为什么还要对tcpip.sys进行修改把这个“半开连接数限制”改大呢？这里主要受益者是P2P应用，在较大的半开连接数限制下，P2P应用可以更快的ping到live的节点，从而提高一定的速度。而普通的网络应用大多是不需要很大的半开连接的。反而是病毒蠕虫为了进行传播，会试图大量建立连接，它们需要很大的半开连接数来保证传播速度。

KDE4.2还是很漂亮滴～～～（也很稳定了～～～）
最新的nvidia显卡驱动也貌似一不小心解决了一个会freeze whole system的bug＠＠

抓了一下包，又本地跑了一个tracker试了试，确定迅雷现在用的peer ID是-SD0100-

话说还有一个-XL0012-的ID的，估计是被屏蔽的太多了速度上不去了改了现在这个ID了，连迅雷自己都不把这个ID在它的列表翻译出来（XL那个ID是翻译成Xunlei的）……

不过话说现在用迅雷下载BT的还真是占大多数呢@@

截图留念

• BT的设计是一款文件分发软件，而不是一款文件分享软件。我们所感受到的BT的源的有效时间比eMule等网络要短很多与这点是有关系的。
• 缺少排队机制，这使得节点连接和传输中含有试探性。
• optimistic unchoke机制——这也是试探性的一种表现，也是缺少排队机制的情况下不得不采用（或者说，如果有良好的排队机制，就不再需要）的一种方法，而正是这种机制使得某些节点可以不上传也能得到还不错的下载速度。
• 同时运行多个BT任务通常是不好的，很多节点都会在选择是否给你上传的时候考虑你对它的上传速度，同时运行多个BT任务（通常）会使每个任务的上传速度都下降——从而每个任务的下载速度都可能会下降。
• 两个节点间事实上可以建立多个连接，即使在只有一个任务的情况下——不应通过ip:port判断两个连接是否来自同一个peer（对于连入连接，port是几乎没有规律的，ip对于同一个内网下的很多peer是相同的）而建立在连接握手消息中的peerID的判断是可以伪造的。

新年新气象，牛年大吉～

Happy Niu Year~

SC和WC总决赛结束，恭喜Grubby

SC方面可以说国人已经很不错了，被上届冠军和本届冠军淘汰也可以理解，相比起来WC可以说比较凄惨，尤其是Sky甚至在小组赛就被淘汰。个人感觉国人的WC的打法有些死板，缺少变化和创新，而在被对手打乱节奏时候缺乏一颗冷静的心。

木瓜大战果然非常精彩，尤其是前两场可谓跌宕起伏，而第三场似乎Moon有些体力不支而显得没有前两场那么有灵性。在此强烈鄙视一下德国方面的OB和导播，随便找一个会玩魔兽的人来都要比这个OB要强，三场比赛下来留下了很多疑点，第一场Moon奇怪的风德脱节，第二场Grubby分矿的情况，第三场Grubby的分矿何时被打爆，Moon的修补匠如何莫名其妙被围杀，初期Moon的农民在Grubby探路苦工旁边造了一个什么神奇的建筑而又退掉，等等等等太多的地方都由于这个SB的OB而没能看到。

第三场Grubby胜利，这时的导播倒是蛮有味道的，一方面Grubby灿烂的笑容，挥舞着国旗，披上国旗向大家致意，另一方面Moon一脸失落甚至是伤心的表情，似乎是在研究replay。Grubby面前无数的闪光灯，而一只手在Moon的肩膀的拍了拍，Moon转头应了一声，这种场面的确很伤感很失落……