幺贰和叁

2012年7月5日星期四

Phenom II X4 955 On C.A780H

之前的CPU是Athlon64 X2 4000+，我娘淘汰给我的。撑了这么多年，实在有些受不了了。整个换I5吧，手上的东西全扔了又太可惜，于是594人刀买了个955。想着我也不去超，这一块七彩虹C.A780H应该可以对付，可事实证明，我想得太简单了…

或许是这块主板太古董了的缘故，虽然CPU型号能正确显示，但默认设置的频率却只有800MHz。痛苦的过程就不表了，最终这块CPU可以稳定跑在如下设置上：

Custom P-Status：Enabled
K10 CPU FID：X16 3200MHz
K10 CPU VID：1.25V
K10 CPU DID：Divided by 1
K10 CPU NB FID：1800MHz
K10 CPU NB DID：Divided by 1

Super PI 1M跑下来22.136秒，Windows 7体验指数7.3，基本正常。虽然折腾了一下，但AM2到AM3保持兼容性这一点上，AMD还是很值得表扬的。

2012年6月25日星期一

rb-readline

不知道从哪个版本起，RubyInstaller的irb就开始有一个Bug，表现为输入或粘贴某些中文字符进去的时候，irb会无提示退出。因为不常遇到，所以一直都懒得查。前两天精神来了就追了一下，发现问题出在rb-readline。

rbreadline.rb文件readline_internal_charloop函数，大概4635行：

rl_setstate(RL_STATE_READCMD)
c = rl_read_key()
rl_unsetstate(RL_STATE_READCMD)
# look at input.c:rl_getc() for the circumstances under which this will
#be returned; punt immediately on read error without converting it to
#a newline.
if (c == READERR)
  eof_found = true
  break
end

READERR的值是0xFE.chr，而GBK和BIG5的编码范围都包括了0xFE，于是这又是一个编码问题。Bug已经提交，我是觉得直接把整个if都删掉就好了，看作者打算怎么改吧。

2012年6月23日星期六

Homemade RaySource

好吧，我们都知道fs2you链接长什么样，自然也看得出来，fs2you://后面的部分，其实是经过Base64编码的字符串。

比如：

fs2you://Y2FjaGVmaWxlMzIucmF5ZmlsZS5jb20vemgtY24vZG93bmxvYWQvYjI3ODI1NzQ2YjgxOWYyMmY1ZGY0ZTFkNTE0NDFjNmQvJUU3JTk0JUIwJUU0JUI4JUFEJUU4JThBJUIzJUU2JUEwJTkxLnJhcnwxMjkyMTEzOQ==

经过解码，可以得到：

cachefile32.rayfile.com/zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar|12921139

竖线符分隔的第一个部分看起来是一个URL，第二个部分则是文件尺寸。有时候竖线符有两个，第三部分是另外一个文件名。通过抓取客户端RaySource的数据包，可以验证以上猜测。

GET /zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar HTTP/1.0
Host: cachefile32.rayfile.com
Accept: */*
Referer: 
Cookie: 
User-Agent: Grid Service 2.1.10.8366
Grid: aWQ9nc3JxpnLys4mcF9udW09MCZkX3NwZWVkPTA=
Range: bytes=0-262144

Grid又是一个Base64字符串，解码后的内容是：

"id=\x9D\xCD\xC9\xC6\x99\xCB\xCA\xCE&p_num=0&d_speed=0"

id均为8个字节，当成GBK字符解码，可以得到四个看起来像天书的中文。p_num可能是process，同时下载多个文件时会有不同的值。s_speed有可能是当前的下载速率，可我想不出为什么服务器会对这个数值感兴趣。

经验证，构造一个类似的HTTP请求，可以用别的下载工具获取文件，比如：

curl --verbose --remote-name --user-agent "Grid Service 2.1.10.8366" --header "Accept: */*" --header "Referer: " --header "Cookie: " --header "Grid: aWQ9nc3JxpnLys4mcF9udW09MCZkX3NwZWVkPTA=" --header "Range: bytes=0-12921138" "http://cachefile32.rayfile.com/zh-cn/download/b27825746b819f22f5df4e1d51441c6d/%E7%94%B0%E4%B8%AD%E8%8A%B3%E6%A0%91.rar"

正常情况下，可以得到一个206响应。只要一切正常，即可直接下载到目标文件。不过就像大家都知道的那样，网络是很不靠谱的。当下载时遭遇断线，构造正常的Range头，如“Range: bytes=1234-12921138”并不能断点续传。

关于这个问题，抓包并没有太大的帮助。RaySource发出的请求中，Range的两个数字除了0和文件的实际尺寸外，均为256KB的正整数倍，且整个Range不超过5MB。嗯，这也太奇怪了点儿。

通过各种尝试，我发现有时候Range的起始值可以是不大于文件尺寸的任意数，且只要Range不大于8000000，也可以获得服务器正确的响应。不过这个有时候，具体是什么情况，我也说不清楚…

嗯，基本上目前就是这样，问题依旧没有解决的说。