更新libantixunle库，该更新版的libantixunlei库堵上了一处内存泄漏
放弃使用VS的编译工具链，改用g++编译，这样就不用以来MFC那些版本乱七八糟的动态库了
GSSXI更新到0.21版本，使用libantixunlei进行迅雷的识别，效率大升。另外，加入了新版迅雷的指令序列。
发现腾讯的超级旋风也开始对服务器造成了影响，看了一下超级旋风的UA，目前看来应该是唯一的。需要连同超级旋风一起屏蔽的GSIXI版本的话，请给GS发邮件。
另外，GSIXI也已经发布新版（这个新版没有包括屏蔽超级旋风的功能），更新记录请看压缩包内文件（GS偷懒不在这里写了……）
GSIXI更新到0.13.4版，已经可以识别迅雷5.7.9.466版本，并修正了0.13.3需要.Net支持的问题。
快报：快车2.0推出正式版。可遗憾的是，经过GS的测试，快车仍然使用和迅雷类似的FTP指令序列。目前最新版的迅雷V5.7.9.472也没有更改FTP指令序列和用户代理。
GSSXI更新到0.20.3版本。
因为快车更改了FTP指令序列，所以加入了一个选项，可以设置“是否允许下载FTP根目录的文件”。如果设置为允许下载根目录的文件，那么使用快车V2.0 Beta 6也可以正常下载；如果设置位不允许的话，使用快车V2.0 Beta 6就会被当成迅雷一起被屏蔽。
另外说一下，基于G6的反迅雷插件已经由rick开发出来，详细情况请看：http://www.ftpse.com/bbs/read.php?tid=5202
已经确定了，迅雷5.7.9.466版本使用了新的用户代理，这个新的用户代理是：Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )（注意，倒数第二个字符是空格）。
其实GS觉得非常奇怪，不知道迅雷为什么要改成这个用户代理。GS猜测，这个用户代理现在绝对是唯一的，这不是有利于我们更准确地识别迅雷嘛。
前几天闹情绪，所以中断了“伪”论文的工作，现在继续开工（论文这东东真不容易写啊）。
最新版本的迅雷修改了用户代理，不过这次改得很奇怪，使我们能更准确地识别出迅雷了。今晚我尽量更新。
心情不好不写论文了
已经查明了，快车2.0Beta6发送的FTP指令序列和迅雷在下载位于FTP根目录下的文件时发送的指令序列相同，所以快车2.0Beta6就被当成迅雷了。
GS会修改GSSXI，增加一个“是否阻止迅雷下载根目录的文件”选项，这样可以放过快车2.0Beta6，但同时迅雷也能下载位于FTP根目录的文件了。其实快车做到今天，GS感觉它已经和迅雷差不多了，似乎也已经开始了大规模盗链，真不知道以后的下载工具会变成什么样，而互联网又会变得怎么样。
昨天有网友说快车2.0Beta6也不能从使用了GSSXI的FTP上下载资源了。GS下载了个快车一试，果然不能下载了。刚才截取了快车的指令序列，发现和迅雷的并不相同。至于不能下载的原因，还要进一步测试。
对了，“伪论文”还在继续完成中，GS会继续努力的。
现在是凌晨1点34分，刚刚完成的GSSXI v0.2 已经投入了测试中。
GSSXI v0.2 新增了以下特性：
- 提供日志功能，可记录GSSXI的启动情况，观察GSSXI是否成功加载
- 提供配置文件功能，可在配置文件中自定义功能和发送给客户端的屏蔽消息
- 提供屏蔽IP功能，可以将使用迅雷的IP屏蔽一定时间
这些功能是根据网友们的建议加上的，欢迎提出你的建议。如果某个功能需求很多的话，GS会考虑加上这个功能。
GSSXI 0.13 的错误已经修复，是由一个测试的字符数组引起的，这数组纯属测试用途，删掉了。
0.14版本已经在开发中，预计会加入IP自动封锁功能。不过要说明的是，Serv-U并没有提供编辑IP规则的接口，因此我们只好自己维护一个IP黑名单，并在用户登录的时候进行判断。这样做的效率会比直接在Serv-U上编辑全局IP规则低。
在GSSXI0.13版本中发现一个严重的错误，这个错误是由链表类引起的。这个错误会导致Serv-U在连接数很多的时候崩溃，现在已经暂停0.13版的下载了。
GSIXI放出0.13版下载。此版本是测试版，在使用前请认真考虑可能造成的服务器不稳定。由于是测试版，没有提供任何设置供用户选择，这个版本的识别后逻辑和处理方法在说明文件内有说明，这里不再重复。
今天发现迅雷目前最新的版本所发送的UA和以前的版本不同。现在发送的UA是类Win2k的，也就是 mz4 ie6 nt5.0。这倒好，根据YT的帖子访问记录UA统计结果，使用这个UA的正常用户更少，如果以后迅雷一直使用这个UA的话，就会有更少的发送和迅雷相同UA的正常用户受到影响了。
昨天收到的反馈，提醒了我这样一个情况。有些FTP服务器会接收到高达每小时几千次的迅雷连接，如果仅仅是断掉连接也会给服务器造成很大的压力。对于这种情况，现在打算使用封IP一定时间的方法应付。
其实对于这样一种情况，还有更好的解决方法，不过这个方法已经超出了识别迅雷连接的讨论范围，但却是一个不错的反迅雷的方法。这个方法GS打算也写到“伪”论文去，其大致原理是根据用户的IP返回不同的目录结构，这样不同IP的用户所得到的下载地址是不一样的。这种方法可以保证直接在网页上单击连接、或通过浏览FTP目录获取下载地址的用户正常使用迅雷下载，而从迅雷的索引获取下载地址的用户无法下载。
GSSXI放出0.13版下载。此版本仍是测试版，但已经可以不依赖.Net Framework，可以独立加载。
GSSXI放出测试版下载。测试版必须在.Net 2.0的框架下才能运行。
明天上课了，怨念……
对GSIXI和GSSXI经过一段时间的测试以后，没有发现什么大的问题，预计这几天可以放出Beta版下载。
GSGXI的开发又见曙光，G6的插件是可以开发的，不过目前我还没找到开发文档。
明天去学校了，怨念……
给GSSXI添加了一个判断，之前没有考虑到文件在FTP根目录时的情况。如果文件在FTP根目录下，迅雷就不会发送CWD指令，因此当迅雷要访问的文件在FTP根目录下时，GSSXI就不能识别出迅雷的连接，更谈不上屏蔽了。
今天竟然已经28号了啊……过得好快……
很郁闷地，本来想今天把论文完成的，可论文竟然被忘在学校了，无奈，只好先发布了技术概览。
留言灌水版完成，预计明天继续写那篇“伪”论文，论文写好以后会和技术概览一起发布出来。
到现在为止，G6还没有回复我的邮件，看来是不会回了，基于G6的反迅雷插件看来没办法开发了。
在樱町网站上对GSIXI进行了一段时间的测试以后，今晚把GSIXI撤了下来，以继续观察效果。
考完试了，接下来可以加快进度开发出试用版本了。这次修改了两个地方。
- 修复GSSXI的一个漏洞，攻击者可以通过发送特殊的指令造成Serv-U崩溃
- 修复GSSXI的记录指令的函数，增加了安全性
忙里偷闲，无视剩下的两科考试，利用今晚的时间完成了几个页面，顺便修改了一下页面结构。
- 完成了GSIXI和GSSIX的页面
- 新增了联系方式页，替换了首页
用了一个晚上的时间做好了界面和基本的程序框架，其他的的几个页面随后补充。明天开始的一周内还有三科考试，先认真对付考试再说。
- 完成了界面和最基本的程序
- 做好了首页和更新日志页