Jie 的个人资料Sunset (hhj's public hom...照片日志列表更多 工具 帮助

日志


2009/5/22

跟风答浙大百事

32分,勉强拿到E,还好不是F。

00.[Y]进过异性寝室:有人没有吗?
01.[N]登上紫荆港校区行政楼楼顶:毕业的时候还没建好
02.[N]参加5.12大地震后升旗仪式:理由同上
03.[N]听郑强讲座:只听说过
04.[Y]挂科:体育x3
05.[Y]通宵自习:西溪东临/玉泉曹楼316
06.[N]在食堂看世界杯:没兴趣
07.[N]在寝室看NBA:同上
08.[N]考100:最高97,电磁场与微波 / ASIC
09.[N]向心爱的男生/女生说“我爱你”:只说过‘喜欢’
10.[N]恋爱:信工光协主席!
11.[N]88或98有万帖ID:职业潜水员
12.[N]吃丹阳蛋饼:啥?
13.[N]在晓风书店坐一下午:啥?
14.[N]玉泉公主楼前打球:不会
15.[Y]紫荆港风雨操场打羽毛球:刚开始不要钱那会
16.[Y]白天睡一整天觉到天黑:通宵赶DEADLINE之后
17.[Y]见过湖滨校区长啥样:这么高的楼,想不见都难
18.[Y]参加BBS版聚:SF版
19.[Y]喝醉:散伙饭
20.[N]点过2斤以上“脉舟”烤羊腿:每次去都客满
21.[Y]见识过“817路”疯狂司机:比过山车都刺激
22.[N]亲历奥运火炬杭州传递:没兴趣
23.[N]出国(境)交流:当时有这个吗?
24.[N]在食堂吃到小强及其族类:浙大的食堂是很好的!!!
25.[N]在紫荆港东一教学楼找不到北:笑话吧
26.[Y]喝过食堂里的免费汤:在差也是免费的
27.[Y]参加2次以上毅行(含2次):2次
28.[N]上过十大:同11
29.[N]玉泉土场打网球:网球课都挂了
30.[N]当过版主:同28,11
31.[Y]有兄弟学校BBS账号:科苑星空算吗?
32.[N]喝过“GP”泉水:啥?
33.[N]吃过紫荆港南区医学院的餐厅:啥?
34.[N]在启真湖畔支过帐篷睡过觉:真浪漫哈……
35.[N]在紫荆港湿地探险:湿地?
36.[N]在“千刀万剐”理过发:啥?
37.[N]上体育舞蹈课:……
38.[N]紫荆港图书馆地下室看星星:没进去过
39.[N]参加校花/校草评选:现在的孩子真无聊
40.[N]结婚或订婚:同10
41.[N]98缘分天空征友:98没帐号
42.[N]88PieBridge征婚:PB不是笑话版吗?
43.[N]98和88都被封全站过:同41
44.[N]获得奖学金:没本事
45.[N]做过学生干部:同上
46.[Y]带父母参观3个以上校区(含3个) :西溪,玉泉,紫金港,之讲,湖滨,华家池(不是一次)
47.[N]在校园里开过车:只有两个轮的
48.[N]在学校厕所涂鸦:……
49.[Y]寝室里集体看片:显然
50.[N]在碧峰篮球场打过夜场篮球:啥?
51.[N]体育考试代考:靠,我当时怎么没想到!
52.[N]送出情书:没文笔
53.[N]收到情书:哈哈哈,555
54.[N]在永谦剧场或zjg小剧场登台:哎
55.[N]在食堂找不到座儿吃饭:我RP好的很
56.[N]打游戏被抓,通报批评:不打游戏我要那么好显卡干什么
57.[N]知道“考研之家”其实是吃饭的地儿:这是什么地方?
58.[Y]考研:真失败
60.[Y]自行车后座载mm或mm被载:哈哈哈
61.[Y]班级旅游:春游,秋游,……
62.[N]和人打架:文明人不打架
63.[Y]旁听你暗恋的人上的课:他们班的老师讲的倒真的比我们班的好(不是借口)
64.[N]到过漂移到紫荆港的“南华园”古建筑:啥?
65.[N]在缘网下过100部以上影片:只下软件
66.[N]在缘网上传100部以上影片:我想上传的上面都有
67.[N]跳蚤市场交易额达一百RMB:啥?
68.[N]去过下沙:久仰大名,但是也没去过
69.[N]买不到过年回家火车票:我的RP真的很好啊,哈哈
70.[N]玩过杀人:在ZJU的时候没玩过
71.[N]吃过斋饭:最大的遗憾
72.[N]在百度酒吧泡妞或勾引帅哥:哪?
73.[N]丢过手机:在ZJU的时候没丢过
74.[N]捡到同学遗失的东西并送还:为什么就没有PPMM的东西让我捡到呢?
75.[N]参加田径运动会或三好杯:我体育都不及格了……
76.[N]寝室里养宠物:不让
77.[N]亲眼见过断桥残雪:号称都是人……
78.[Y]去过双溪漂流/九溪烧烤/梅家坞吃茶/植物园(至少完成3个):后三个
79.[N]在UME看英文原声电影:就看过《Star Wars: Revenge of Sith》,还是配音版的
80.[Y]观看西湖音乐喷泉:哈哈哈
81.[N]搭讪异性同学:什么叫搭讪?
82.[Y]参加过校内社团:有没有的吗?
83.[Y]与别人撞衫:天天校服天天撞
84.[N]夜里操场跑圈10圈以上:……
85.[Y]丢过校园卡或银行卡:银行卡,学生证,身份证,借书证,饭卡,一次全丢……
86.[Y]去过上交和复旦:兄弟院校一日游
87.[N]学校与机场间打车:这人真有钱啊
88.[N]参加补考:没有补考
89.[Y]被表白对象拒绝:很多次
90.[N]被应聘公司/申请学校拒绝:我觉得我应该去买彩票了
91.[Y]拿到应聘公司/申请学校OFFER:嗯
92.[Y]被偷车:丢过一辆巨破的,这贼真没品位
93.[N]选必修课全被踢:难道现在学生有这么多……
94.[Y]和紫荆港校门的石头合影:毕业前的必修课
95.[Y]去看钱江潮:四年看了三次
96.[N]给老师买过花:开什么玩笑
97.[Y]考过TOEFL或GRE:哈哈哈,都挂了
98.[Y]在“小西天”看病:补牙

2009/5/18

《星际迷航中的物理学》(The Physics of Star Trek)

    前段时间在A. C. Clarke的3001: The Final Odyssey的后记中看到他提到这本书,正好最近又赶上Star Trek XI热映,就跟风从图书馆把这本书借来看看。很多人看科幻片都喜欢挑硬伤,而Star Trek本来又不是一部在科学原理上很严谨的电影,长久以来给Star Trek挑刺的文章可谓层出不穷。现在好了,让我们跟着真正的内行一起来找X吧。虽然内容比较浅,但语言生动,逻辑严谨,不失为一本很有意思的闲书,在此推荐一下。以下是该书的详细索引:

Lawrence M. Krauss, The Physics of Star Trek, HapperCollinsPublishers, 77-85 Fulham Palace Road, Hammersmith, London, W6 8JB, 1996 (ISBN: 0-00-225485-9)

2009/5/13

关于A-H1N1流感

    英国65例了,数字还在稳步增加中。街上没人带口罩,倒不是说这的人比较不要命。卫生部说口罩没有用,要预防最好的办法就是多洗手,以及少去人多的地方,于是大家就信了。卫生部还说,就目前的状况看,A-H1N1流感的死亡率很低(0.1%),大多数就医者(尤其是较早就医者)的的症状都比较轻微,大家也信了。所以大街上的景象一如既往,也听不到人们经常议论流感的事情。

    6号研究生毕业典礼,主持人说,介于目前的卫生形式,今天握手就取消了吧。但是后来校长跟每个毕业生都握了手。学校,地铁,博物馆和其它社会机器都在正常运转。吃饭的时候偶尔听到有人提到,总会有人开玩笑的咳嗽两声,然后大家就一片轰笑。

    发现新的疑似病例后,对一片人群的隔离、筛查和发放抗病毒药物等措施一直都在进行。疾病还在扩散中,NHS官员在今天的讲话中刚刚证实。但应对计划在多年以前就准备好了,因此所有的行动都迅速而安静。

    对A-H1N1流感,没有人有抵抗力,除了相信政府机构对疾病的控制,其实也就只能听天由命了。所以恐慌有什么用?还不如好好的过自己的日子。

==========我是分割线==========

    中国2例。几天前才有的,两个都是从国外回来的留学生。和其它的跨国传播案例如出一辙,刚到港的时候还在潜伏期,几天之后才开始发病,发现时已经晚了。中国很大,几乎每个大城市都有国际机场,有些还很繁忙,这样的事情其实无法避免,最多只是个时间问题,所以我一点都不觉得惊讶。

    现在国内的大论坛上似乎都在骂这两个孩子,骂的很损,很难听。似乎没有人同情他们,因为他们是‘汉奸’,是‘不顾国家利益的小人’,是‘留学垃圾’,是……然而他们也是病人。不管怎样,他们首先是病人——在网上谩骂的人起码还是健康人。

==========我是分割线==========

    我不想多评论什么。对于英国人的态度,那两个孩子的态度(行为),网友的态度,我全部都可以理解——至少我相信我确实是理解了。很矛盾,不是吗?但没有矛盾的社会有有什么意思呢?

==========我是分割线==========

    介于目前流感大流行(Influenza Pandemic)的威胁近在咫尺,有朋友问我,你怕死吗?我说我不怕。因为我相信人类社会是一个整体。人和人之间的交互(现代通信技术在其中功不可没)使所有人的思维汇聚在一条洪流,一个不朽的整体。即便我今天就死掉,也会有人(即便只是很少的几个人)记住我,用我的工具,继续我的研究。即使微乎甚微,我存在过、思考过、影响过,这已经足够了。也有人问我,你做这些没啥用的研究到底有什么意义?我想这也算是部分的意义吧。

==========我是分割线==========

    于是我还是继续去搞我的试验吧,毕竟我能做的也就是这些了。

2009/3/30

How it Happened, by Isaac Asimov (艾萨克·阿西莫夫)

在图书馆淘到一本阿西莫夫的段篇集,发现这篇很有意思,在国内的时候似乎没见过,正好又很短,于是就翻译如下:

    我的弟弟开始用他极富渲染力的口吻——正是这种口才使整个部落都尊从于他言辞——讲道:

    “太初之时”他说“正是152亿年前,首先是大爆炸,然后宇宙——”

    我停下了笔。“152亿年前?”我一脸惊讶。

    “千真万确”他答道“我受到了启示”。

    “我不怀疑你受到的启示”我说。(最好不要怀疑。尽管他比我年幼三岁,但我从不怀疑。其它人也是一样,否则只有自讨苦吃。)“但你的意思是,你要将整个150多亿年的‘创世’故事全告诉我?”

    “我必须如此”我弟弟说到“这就是它所花费的时间。全在这里呢,”说着他拍了拍自己的脑门,“而且拥有至高无上的权威。”。

    但我却把笔放了下来。“你知道莎草纸的价格吗?”我说。

    “什么?”(也许他确实受到了启示,但我总是注意到他受到的那些启示似乎从不包括任何和现实利益沾边的东西,比如莎草纸的价格)。

    我说,“假设你用一卷莎草纸讲述100万年的事情,这也意味着15000卷。你得用很长很长的时间才能把这些故事讲完——而你也知道,说不了多久你就会开始口吃。我也得写花很长很长的时间才能把它们写下来——假如我的手指头不先断掉的话。退一步说,就算咱们有钱买那么多卷莎草纸,而你我又有足够的能耐把你的故事写完,谁会去传抄它?咱们要出版你的故事,怎么说也得有几百份抄本,不然哪来的版税?”

    我弟弟想了一会,说到“你觉得,我应该把这个故事缩短一点?”

    “大幅削减”我说“假如你真希望能让大伙看到它。”

    “那一百年怎么样?”他问到。

    “六天怎么样?”我说。

    他看来真被吓到了,“六天?!无论如何也不可能把创世的故事压缩到六天!”

    我说,“实话告诉你,我手里这些莎草纸就只够六天。写还是不写,你拿主意。”

    “那么……好吧,”他重新郑重其事的口述起来,“太初之时——真的只能有六天吗,雅连?”

    “没错,就是六天,摩西。”

2009/3/12

East Acton

East Acton,23:22 GMT。

    列车加速的并不块,用了好几十秒才慢悠悠的驶离了月台。随着最后一节车厢也逐渐隐没在淡淡的雾中,站台上又恢复了宁静,只偶尔还能看到远处列车的电刷和第三轨之间闪过的一两道电弧。

    这一站和其它的郊区小站并没什么区别。一样陈旧的设施,一样的LED点阵显示器,几盏高压水银灯,白色的木头栅栏,坑坑洼洼的水泥月台和边缘上一道掉了些颜色的黄漆警示线。站台离地面大约有两层楼的高度,周围一片都是住宅区,一栋栋一两层的带阁楼的尖顶小屋一直绵延到很远的地方。空气中悬浮的水珠散射着灯光,给每一扇窗户都画上一圈薄晕。四周水汽很重,偶尔一阵凉风吹过,便能闻到一股雨后泥土的味道。我靠到栅栏上,闭上双眼。周围静的足以辨识出基频50Hz的背景噪音。

    又一阵风吹过,泥土的气息更浓了。一些意像开始从黑暗中浮现出来。最先出现的只是气味,一股同样的泥土气息。然后是同样的寂静和台灯发出的若有若无的震动声。之后便有了光。橙黄色的灯光只照亮了书桌上很小的一片范围。光圈照亮的是一堆码放的很不整齐的打印材料,上面压着一盒20包装的雀巢速溶清咖啡、一个头戴破帆布帽的流氓兔瓷娃娃和一台正在与电脑同步的惠普iPAQ PDA。我蜷在椅子上,抱着腿皱着眉头看着屏幕上的图像。编解码或传输过程仍然存在问题。错误的运动补偿正在往视频图像上叠加着一层又一层的残像。然后是一个解码失败的关键帧,几个品红色的宏块显的格外刺眼。我无奈的摇了摇头,端着茶杯从书桌前站了起来。右面的柜子上挂着一块花了70块钱从浙大超市抱回来的白板,上面密密麻麻的画这一堆流程图、状态转换图和一些我从来没再看过第二眼的工作记要。

    虽然只是初春,气温已经暖和的足以让我们选择在夜间也开着窗户保持空气流通。入夜之后外面就一直时断时续的飘着小雨,让吹进寝室的风里也夹带着几丝清香。斜对面的房间还在打牌,时不时爆发出一阵放肆的笑声。但寝室里的另三位兄弟早已自动补偿了这种高度周期性的背景信号,依然在床上睡的很安稳。我推开房门,拉了一把椅子在阳台上坐下,静静的注视着眼前的画面。夜已经很深了,对面的30舍只零星有几个窗口还闪着灯光。阳台的栏杆上湿乎乎的挂满了水珠,不知是露水还是雨水。天空中的云层仍然很厚,将月亮遮蔽的严严实实,让远处的老和山只剩下一片模糊的黑影。另一边是市区,远处的黄龙体育中心、电信大楼和周围新建的一片高档商品房依然灯火通明,映的天空也呈现出了一片奶油般的色彩,正随着霓虹灯广告牌上的图案有规律的变化着色调。似乎有些困了,眼皮不自觉的搭了下来。四年的大学生活就这样无可避免了翻到最后的两三页。满怀激情的大一,彷徨不安的大二,充满回忆的大三和失落而又充实的大四,无数的慢镜头从眼前中疾驰而过。四年的时间仿佛刹那间便塌缩成了这寥寥几百万个字节的语义网。最后是保研被刷的那一刻,我似乎清晰的见到了一条以时间为轴的分段光滑曲线上出现了第三个清晰而尖锐的折点。无数不可测的平行空间便一瞬间发散了开来。突然,一个念头划过脑海:下一个四年之后是否还会有一个相似的夜晚,而我又会在哪里幻想着些什么呢?

    已经被摔断了电池盖的LG MP3正放到老狼的一首老歌:

    关于未来你总有周密的安排 
    然而剧情却总是被现实篡改 
    关于现在你总是彷徨又无奈 
    任凭岁月黯然又憔悴地离开 
    出乎意料之外 
    一切变得苍白 
    你计划的春天有童话的色彩 
    却一直不见到来 
    你撒下的鱼网在幸福中摇摆 
    却总也收不回来 
    你始终不明白 
    一万个美丽的未来 
    抵不上一个温暖的现在 
    你始终不明白 
    每一个真实的现在 
    都曾经是你幻想的未来

    周围开始有了些别的声响。先是铁轨上偶然传来的震动,而后逐渐汇聚成一串规律的、频次逐渐降低的车轮撞击轨道连接缝的轰响。再之后便是刹车声和车站提示。与此同时,另外一个重叠的场景正在迅速的消退、压缩、归档,以至终于不再可见。最后是车门打开的声音。车厢里明亮的日光灯管重新给两侧的月台撒上一层信息时代坚定的真实感。

    我看了看表,23:26 GMT。论文初稿还有73小时的时限,但已经问题不大了。之后便可以重新回到工具链和平台的开发工作上了。还有搬家,正式注册,调整工资。这些事情都解决了,也许就可以回趟国了吧?

    你始终不明白,每一个真实的现在,都曾经是你幻想的未来。

2009/2/26

巧克力咖啡豆

没想到还有这么夸张的食品……

刚才在学校的小店里买点心,发现放干果的那个柜台上又来了点新花样,其中有一种叫Chocolate Coffee Bean。自从上次上了Wine Gum(一种果味软糖,其实完全不含酒,之所以叫Wine Gum是因为人们认为它的口感像酒——别问我他们是怎么想出这个相似性的,反正我觉得一点都不像)的当之后,我就不大相信这些奇奇怪怪的名字了。看看也不贵,一包100g装的98p,和一般的干果差不多,于是我就买了一包想尝尝这个‘巧克力咖啡豆’到底是什么东西。

打开之后,立刻闻到是一股浓郁的咖啡香味,心中一惊——这回难道是真的?放了一颗在嘴里,巧克力里面果然是一颗充分哄焙过的咖啡豆。翻过来仔细看了一下配料表,再次确认他们用的确实是咖啡豆而不是脆饼干。天哪,这样一包得含多少咖啡因!本着对健康负责的态度,我立刻在网上小搜了一把:

* http://www.WikiAnswer.com 上的说法是根据所使用的咖啡种类不同,每颗这种豆的咖啡因含量大概在10~20mg之间。

* http://www.fitbit.com/foods/Dark+Chocolate+Coated+Coffee+Bean/27769 上有一个详细的营养列表,其中的说法是每5g这种食品含有咖啡因42mg。

* http://www.hackerstickers.com/products/shock-a-lots-chocolate-covered-coffee-beans.shtml 是一个这种糖果的广告页面,上面的说法是每6颗这种豆的所含的咖啡因大约相当于一杯咖啡的含量(120mg)。

综合一下这三种说法,刚才买的那一包(100g,大约有50粒)的咖啡因含量估计在500~1000mg之间。对照 http://www.bbc.co.uk/health/healthy_living/nutrition/healthy_caff.shtml 所给出的常见提神饮品的咖啡因含量,这个剂量大约等同于7~13杯速溶咖啡、4~8杯使用摩碎的咖啡冲泡的咖啡、10~20杯茶或10~20听可乐。尽管目前尚没有确定的针对咖啡因的最大摄入剂量建议,但:

* NHS认为妇女怀孕期间的日均咖啡因摄入不应高于200mg(http://www.nhs.uk/news/2008/11November/Pages/Newcaffeineadviceinpregnancy.aspx)。

* [R. Griffiths, P. Woodson, 1987](http://www.springerlink.com/content/wl412194360xj32t/)指出在短期大量摄入咖啡因(连续6~15天日均摄入量大于600mg)并停用后的人群中可观察到戒断综合症。

这样看来,一包100g的巧克力咖啡豆——如过真的当小点心吃,10分钟就可以吃完——的咖啡因含量似乎是不大安全的。而这样的东西居然和普通的干果放在一起卖……哎,先放着吧,一定要注意千万别一会饿了把它当巧克力豆都吃完了。

2009/1/22

更新一下

    有同学问我,N年不更新日志,是不是因为忙得。不是。我现在每天除了来实验室玩上12小时,啥事都没有。这样简单而纯粹的生活,难道还不够轻松么?实话实说,我就是懒得更新,反正更新了也没人看。不过想不到居然还有人催我更新,在下顿时感动的泪如泉涌,遂决定写两句废话充数。

    昨天看天气不错,去学校的时候就早了两站下车,从海德公园里面穿了一下,发现我的实验室离公园居然那么近!根据步数换算,我的办公桌到公园大门的距离只有区区283.2米。这么近的距离,我居然算上昨天也只去过两次。罪过啊,环境资源不是这么拿来浪费的。以后一定要多去玩玩,不然实在对不起去年一年N贵的学费。

    下午边乱捣腾串口线边吃了一包巧克力。英镑兑人民币都跌到9.48了,还攒什么钱啊,就这么点工资,还不如都在这边花掉算了,起码吃掉还算保值。下午还有一个收获,就是知道了有插头的接口叫male,有插孔的叫female,插孔转插头的转接头叫gender changer。以前在88上看到过,还以为是笑话,没想到居然是真的,不服不行!

    哦,对了,话说真的可以通过把SND接到RCV的方式让串口给自己发数据。嘿嘿,估计知道这个的人不多吧(画外音:那是因为没多少人会无聊到这个程度吧)。

    最近终于被迫直接对着反汇编调试程序了,还真是刺激啊。不过幸好出错的地方很快被定为到NTDLL.DLL里面,而且还有一条完整的调用栈轨迹。要是被定为到一个什么乱七八糟的第三方库里面那可真的要抓狂了。最后发现居然是因为在双核上运行了真正的并发指令而导致的竞赛条件造成的,什么衰事!当初开发这东西的大牛估计还因为自己靠熟悉编译器和操作系统想出这么‘优化’的代码(由于所有对该地址的访问都被编译为原语级指令序列,所以不需要加多线程保护)在那暗爽呢吧。

    刚才看到校内网上某朋友的日志,他居然都到考研的时候了。我大学毕业那年他大一。我的大学四年似乎还是昨天的事情,一晃居然又快四年了。这几年我都干什么去了……

    不写了,还是代码和论文更有真实感啊。

2008/11/12

气节

    不知道是我疯了还是社会疯了,自从‘潜规则’这个词被发明以来,它几乎在一瞬间以惊人的速度迅速蔓延到了报纸的每一版上。从最初的娱乐界到商界、政界甚至学术界,终于每一个犯了错误的孩子的都可以在这铺天盖地的潜规则面前摆出一副“人在江湖身不由己”的无辜面孔,于是仿佛这一切的错误都顿时成了社会的责任,而行为主体反而倒成了应当被同情的对象。诚然,社会制度的缺失是一个理由,但作为行为主体的人,难受除了随波逐流之外就没有任何其它的选择吗?中华文化几千年来传承以久的气节和操守都死到哪儿去了?连学生抄袭论文被抓都以潜规则为自己辩护,我实在不知道该对这些孩子说什么好了。深夜吐糟,不欢迎拍砖。

附某报道连接:http://news.xinhuanet.com/school/2008-10/21/content_10227208.htm

2008/11/11

LOG_2008_11_11

Last week was a bit messy. Due to various reasons, I have not achieved mush during the past 10 days. Thus there are not really many things to mention. Nonethless, leaving a short record is still a good thing.

Firstly, I have tested the code package of the Point Detector. BUGs were not found but unfortunately my computer crashed during the installation of the preliminary software. It costed me days to restore my computer back to normal, which was a definitely an unproductive waste of time. Then, I have investigated a little bit into the issue of synchronizing video, audio and gaze tracking streams, which would be captured by different computers. Many methods, including using camera trigger signal or GPS time stamp as extra sychronization data, have been studied. However, the final solution will still largely dependent on how the gaze tracker exactly works. Therefore, most of the discussion was virtually based on our own speculation and thus is useless unless we can get more technical detail from the producer of the gaze tracker.

The third issue, which really counts, is that I have modified the framework with respect to the points mentioned in LOG_2008_10_31. Usage of references and pointers are now in consistent manner and the PublishMessage function would use the full allocated time trying to send out messages whenever possible. Nevertheless, the direct P2P communication was still not introduced yet due to the mass modification work it may require. I have also given some thoughts on how our framework might be extented to supported multiple hosts. But because only very initial idea exists so far, I would rather to describe the whole design some time later. Old version of the framework and its test projects are now officially filed.

Development of the demo system was started last week but was then interrupted unexpectedly. This will be my main task in the following 2 weeks.

To keep a reminder, I also need to:

* Finish the time sheet.
* Get a libary card.
* Ask the CSG people to adjust my login ID's privilege.

2008/10/31

月底总结

    用两个字总结本月,那就是充实。如果描写的详细一点,那就是眉头紧锁,咬牙切齿的从牙缝里挤出几个字:“充实,太TMD充实了”。首先是忙。做项目是很有意思的事情不假,但确实也挺累的。我又不是工作狂,所以有点怨言应该也在所难免。不过也只是一点点怨言而已,其实总的来说还是有意思的成分占大部。那么为啥做这个表情呢,倒不是因为恨,而是因为这个月真的是太充实了。

    从月初说起吧。注册的事情,合同的事情,工作许可的事情,几经反复,真有点大起大落的感觉。具体的故事就不说了,反正跟我熟的人都已经知道了。不过好在现在事情都结了,身份问题也算有了着落,所以就不说了。剩下的时间主要就是做项目了。不过项目的具体情况我就更不想说了。倒不是因为郁闷或者别的什么事,主要是因为工作日志都写在MSN Space上,很详细,我就懒得重复了。有兴趣的朋友自己去看吧,不过估计也没几个人真有兴趣,呵呵。

    既然正事都不想说,就说点乱七八糟的事吧。我也懒得建什么逻辑结构了,以下就全用Bullete Points(谁能告诉我中文该怎么说?必有重谢)吧。

* 今年新的博士生似乎比以往多不少,是因为经济危机吗?工作不好找了于是就更倾向于读博士了?原因是我胡猜的,不过这条事实应该是准确的。

* 学生卡没了,拿着临时卡在食堂吃饭都不打折。不打就不打吧,售货员还经常忍不住好心问我为啥没有学生卡。虽然知道他们是好心,但老得花时间解释也挺烦的——肚子饿,受不了啊。后来我就直接把临时卡拿出来说我就是一Vistor,能不能打折您看着办吧。这样的确快不少,但是也有心特善的,拿着我的临时卡刷好多次,自然没用(我说了,不过她不信),她还不罢休,跑去问主管为什么这卡用不了……不过也有运气好的时候。有一次我说我没卡,那个售货员直接问排在我后面人说能不能把你的学生卡借来用一下,我正纳闷这是要干啥呢,她用那人的卡刷了,然后语重心长的跟我说,你看,这样不就便宜多了,下次记得带卡啊。看来还是装新生小正太比较有前途。

* 二楼那个便宜又好吃(相对的!)的食堂居然没了,改成了一个又贵又难吃的自助,真郁闷。不过校园小报Felix上已经连续两次批评这个举措了,也许过段时间能改回来吧?盼望中……

* 买了1~3区的地铁月卡,一算发现自己几乎在亏的边缘上。月卡是109 GBP,如果一天乘一个来回那就是22~24天的钱。也就是说我只要一个工作日不去学校就亏了。遂决定一定要养成以实验室为家的好习惯。要做到每周保证来五天,争取来六天,偶尔来七天,每天至少待10小时,认真工作,认真学习。我在此,向祖国和人民发誓:如果我做不到,我就对不起领导,对不起党,对不起人民,我就不配做一个中华人民共和国的公民……得,这又岔到相声(《十点钟开始》,好段子啊!)上去了。

* 找到了传说中的特拉法加广场里那些“不要喂鸽子,因为它们已经越来越讨厌了”的牌子。看来这事是真的。可惜啦,小时候一直想来看看这个著名的鸽子广场,结果等我来了,鸽子不见了……

* “居里夫妇一块在实验室里废寝忘食的提纯镭真是世界上最浪漫的事”——居然这样‘BT’的论断都有人认同,大好大好。不过也借此认识到了囚徒困境(Prisoner Dilemma)的普遍性。另外也以实践证明了一个巨弱智的解决囚徒困境的方法——信息交换,然后就从多均衡退化到单均衡了(某人大吼:靠,这是玩赖!)。

* 参加了一堂助教培训课,发现批作业原来比我想象的辛苦多了。终于认识到了我去年把要求两页的报告写到十页是一件多么可恶的事情。下学期也许就要做这活了,又不多给钱。虽然不太想花这工夫,但是心想自己从写作业的人‘升级’成了批作业的人,也挺爽的。

* 实践再次证明,计划永远是完不成的。预计一个星期的活做了两个多星期,还是在紧赶慢赶的情况下。

* 发现居然有人(白人)姓Westgate,这不是‘西门’么!真是牛X的姓氏。如果有人叫Snowdrift Westgate那就更好玩了[Tang F., 2008]。

* 把9月买的几个高达模型做了,过两天上图。不过我手艺不好,做的很烂,到时别拍我砖就是了。

* 最后,关于上篇日志。相信因为这个我已经彻底被一些人看扁了——虽然留言里面没有反映。不过话说回来,你要是BS某人还会去留言吗?关于那篇纯发泄我也没啥可解释的,反正熟悉我的人都知道故事的来龙去脉,也知道我是个啥人,那就成了。

* 最后的最后,我似乎又有了争取以后去美国玩几年的动力。大好大好。

LOG_2008_10_31

Here are some thoughts on how to further improve our own framework.
 
First of all, a small issue is that we may change the function interfaces a little bit in order to achieve consistency in usage of pointers and references. Overloaded functions may be added for this purpose in order to replace the default argument value mechanism which we are using now. 
 
Secondly, we may change the the PublsihMessage function to better guarantee communication reliability. Note that the reliable message delivery is not always guaranteed in our framework. In particular, message transmission could be failed if there does not have enough space for the message in receiver's inbox at the moment. This could happen in two situations. In that first case, the message is larger than the size of the receicer's inbox. Here, it is simply impossible to put the message in anyway and thus specifying a larger inbox size would be the only solution. But in the second case, where the receiver's inbox is sufficienctly large but still can not hold the newly published message because of lack of of free space, our current implementation would simply return FALSE to indicate failure, which is not the best approach. An improvement is to wait for a while until the receiver's Inbox Monitoring Thread retrieves some old messages to eventially free enough space for the newly arrieved one. Of course, a timeout value should be applied as well to avoid infinite wait in certain circumstances (e.g. when clushes with client log-off / unsubscription).
 
Finally, we also give some considerations to message re-sending. Here are many ways to do this. One possible solution is to create a pivate channel for each client, and thus P2P communication could be implemented. This requires no change to current framework architecture but may not be that straightforward to developers. Another solution is to embed this P2P communication supports directly into our framework's SDK. The second method may be more welcomed by developers but would in turn require significant extensison to current design of the framework. More consideration regarding to this issue is still needed before we make our final decision.
 
Finally, despite this is another night in lab for me, I would still wish a Happy Halloween to those who are lucky enough to enjoy their life better. 
2008/10/30

Comparison between ActiveMQ and our own framework

Comparison between ActiveMQ and our own framework

******************** Conceptual Comparison ********************

                      | ActiveMQ                   | Our Own Framework
-----------------------------------------------------------------------------------
1.Supported           | Java (through JMS),        | C++ (through our SDK)
  Languages           | C++ (through CMS),         |
                      | and etc.(not studied)      |
-----------------------------------------------------------------------------------
2.Supported OS        | Windows, Linux, Mac        | Windows
-----------------------------------------------------------------------------------
3.Provided            | Publish / Subscribe        | Publish / Subscribe
  Communication       | (through Topics),          | (through Channels);
  Domains             | Peer to Peer               | All modules must
                      | (through Queues);          | be running on local
                      | Modules can reside         | host
                      | on different hosts over    |
                      | intranet / internet        |
                      | * See [Note 1]             |
-----------------------------------------------------------------------------------
4.How Modules         | As standalone EXEs         | As standalone EXEs
  are Implemented     |                            |
-----------------------------------------------------------------------------------
5.Configuration of    | Only dynamic               | Only dynamic
  the System          | configuration is           | configuration is
                      | supported                  | supported
                      | * See [Note 2]             | * See [Note 2]
-----------------------------------------------------------------------------------
6.Underlying          | TCP                        | Shared Memory for data
  Communication       |                            | message delivery and TCP
  Method              |                            | for management message
                      |                            | (used internally) delivery
-----------------------------------------------------------------------------------
7.Reliability in      | By default, reliable       | Reliable ordered message
  Communication       | ordered message            | delivery is guaranteed
                      | delivery is always         | only if all modules' in-box
                      | guaranteed (but            | are reasonably large.
                      | developers can tune        | Nonetheless, in cases when
                      | parameters in order        | some subscribers do not get
                      | to better balance          | some message, the publisher
                      | reliability and            | would get reports immediately
                      | efficiency) at all         | after message publication.
                      | cases.                     |
                      | * See [Note 3]             |
-----------------------------------------------------------------------------------
8.BUGs and Stability  | Memory leak is detected    | No known BUGs yet
                      | when using its SDK. But    |
                      | despite that, the SDK      |
                      | and the broker are quite   |
                      | stable, at least no        |
                      | deadlock or abnormal       |
                      | termination has happened   |
                      | during my test             |
-----------------------------------------------------------------------------------
9.Configuration of    | Configuration of the       | To use our SDK, developer
  the Development     | development environment    | simply needs to include the
  Environment and     | for ActiveMQ is quite      | LIB and header files into
  Documentation       | complicated. Many          | his / her own project. We
  Support             | component of the entire    | have provided sample
                      | toolkit are only           | programmes and all of our
                      | provided in source code    | APIs are well documented.
                      | packages rather than       |
                      | binary distribution.       |
                      | Only to compile them       |
                      | could cost considerable    |
                      | amount of time and         |
                      | effort. Adding to this,    |
                      | because ActiveMQ and       |
                      | ActiveMQ-CPP rely on a     |
                      | number of other open-      |
                      | source projets, strange    |
                      | problems, which are not    |
                      | documented, may appear     |
                      | due to version             |
                      | inconsistency between      |
                      | these projects. But to be  |
                      | fair, ActiveMQ-CPP does    |
                      | provides some small        |
                      | examples and comprehensive |
                      | documentation for all its  |
                      | APIs. [URL 4]              |

[Note 1]

An ActiveMQ-based system often consists of a number of modules, which are implemented as standalone EXEs, and a message broker, which acts as the system manager and message dispatcher. Since ActiveMQ is an (extended) implementation to JMS [URL 1], both Publish / Subscribe (P/S) and Peer-to-Peer (P2P) communications are supported [URL 2].

Here, ActiveMQ's implementation to P2P communication is quite interesting. In its implementation, messages are not directly sent to the receiver but to a broker-managed entity called a 'Queue'. To retrieve messages, the receiver should subscribe to the queue, just like subscribing to Topics (equivalent to Channels in our framework) in P/S domain. As we can see, this scenario is very similar to P/S communication. Nonetheless, there do have some differences. First of all, unlike Topics, a Queue can only have up to one receiver at any time. Secondly, a Queue maintains a buffer to hold received (by the Queue) messages if it has no subscriber at the moment [Note 4]. These buffered messages would be sent to any new subscriber immediately after its subscription. By contrast, messages sent to a Topic with no subscriber are simply destroyed in no time. ActiveMQ's 'strange' implementation to the P2P communication eliminates the necessity of having ID for all clients (but ID can be still assigned), which is an interesting fact. Ideally, only Queues and Topics have ID, as they are called Destinations, and this is already sufficient for establishing any forms of message communication within the system.

The interface of the P/S communication domain in ActiveMQ is very similar to that in out own framework. However, their underlying implementations are significantly different from each other. In ActiveMQ, C/S architecture is exploited. Namely, each client establishes and maintains a TCP connection to the broker (server) at all time, which is used to delivery data messages. When a message is published, it would be firstly sent to the broker and then dispatched to all subscribers with respect to the subscription information, all through these TCP connections. Although our own framework also requires the establishment of TCP connections between clients and the server, they are only used to delivery system management message. Data messages are always delivered in a P2P manner through the specially designed Shared Memory based protocol in our framework. Conceptually, it is expected that ActiveMQ's TCP based implementation should be far less efficient (in terms of maximum data throughput and resource consumption level) than our Shared Memory based method. Moreover, ActiveMQ's C/S architecture would also concentrate the pressure of the broker when during with concurrent communications.

[Note 2]

Dynamic configuration means we do not have a static configuration file for the system, which can be load and parsed by some manager and enable user or developer to start the entire system in a single command. Instead, we hard code pieces of subscription information into each module's own programme implementation, and manually start them one by one in execution. Comparing to the other method (static configuration), static configuration is less convenient but yet more flexible.

[Note 3]

In the most extreme case, messages would be saved into disk file and are guaranteed to be delivered even in situations when broker itself crashes. However, this is the most inefficient case. By contrast, the developers can totally cancel the reliability guarantee mechanism in order to achieve higher efficiency. A number of parameters have been introduced to enable developers to better balance between reliability and performance. [URL 3] gives a detailed description to all these parameters. In the following quantitative tests, the default configuration, which is also used by ActiveMQ-CPP's example programme, is used for it best fits into our requirement in communication reliability.

[Note 4]

This mechanism will cause the sender to wait infinitely if it keeps sending messages after the Queue's buffer is already piled full.

******************** Quatitative Comparison ********************

In order to derive quantitative comparison results in terms of data throughput, message delay and resource consumption level, two test programmes have been developed. One uses ActiveMQ while the other exploits our own framework. In each of the test programme, a message receiver and a message publisher are implemented. The message publisher continuously does the following in a worker thread: {Publish a message; Sleep 10 ms}. Here, length of the published message is configurable and the sleep operation is used to avoid 'busy waiting' when the message length is short. In the mean time, data rate, average message delay is calculated and displayed by the receiver. Note that because message publication takes time, the packet rate can never reach 100 P/s. The long it takes, the lower the packet rate is. In addition to the quantitative results, I have also added '* High CPU Usage' tag to some rows to indicate that the overall CPU consumption at these situations are over 50% (obviously can not be tolerated in real application). The tests were running on a ThinkPad T43 laptop computer, with 2.0 GHz Intel Pentium M processor and 1.0 GB of physical memory.

1. ActiveMQ

1.1 Send to a Queue

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB             83 KB/s          1.06 ms        83.00 P/s
   4 KB            331 KB/s          1.16 ms        82.75 P/s
  16 KB           1.10 MB/s          3.25 ms        70.40 P/s
  64 KB           2.94 MB/s         11.63 ms        47.04 P/s * High CPU Usage
 256 KB           5.80 MB/s         33.77 ms        23.20 P/s * High CPU Usage
1024 KB           7.28 MB/s        155.30 ms         7.28 P/s * High CPU Usage
4096 KB           5.26 MB/s        988.41 ms         1.14 P/s * High CPU Usage

1.2 Send to a Topic (1 Subscriber)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB             82 KB/s          1.04 ms        82.00 P/s
   4 KB            327 KB/s          1.22 ms        81.75 P/s
  16 KB           1.09 MB/s          3.26 ms        69.76 P/s
  64 KB           2.74 MB/s         11.72 ms        43.84 P/s * High CPU Usage
 256 KB           6.00 MB/s         30.22 ms        24.00 P/s * High CPU Usage
1024 KB           6.40 MB/s        145.28 ms         6.40 P/s * High CPU Usage
4096 KB           5.20 MB/s        727.39 ms         1.30 P/s * High CPU Usage

1.3 Send to a Topic (3 Subscribers)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            75 KB/s           2.00 ms        75.00 P/s
   4 KB           277 KB/s           2.80 ms        69.25 P/s
  16 KB           854 KB/s           7.64 ms        53.38 P/s * High CPU Usage
  64 KB          2.00 MB/s          20.24 ms        32.00 P/s * High CPU Usage
 256 KB          2.72 MB/s          79.31 ms        10.88 P/s * High CPU Usage
1024 KB          3.31 MB/s         288.23 ms         3.31 P/s * High CPU Usage
4096 KB          2.82 MB/s        1392.08 ms         0.71 P/s * High CPU Usage

2. First Example Framework

2.1 Send to a Channel (1 Subscriber)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            93 KB/s           0.02 ms        93.00 P/s
   4 KB           366 KB/s           0.05 ms        91.50 P/s
  16 KB          1.41 MB/s           0.08 ms        90.24 P/s
  64 KB          5.73 MB/s           0.01 ms        91.68 P/s
 256 KB         22.82 MB/s           0.05 ms        91.28 P/s
1024 KB         73.26 MB/s           2.92 ms        73.26 P/s
4096 KB        171.47 MB/s          13.70 ms        42.87 P/s * High CPU Usage

2.2 Send to a Channel (3 Subscribers)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            91 KB/s           0.04 ms        91.00 P/s
   4 KB           364 KB/s           0.05 ms        91.00 P/s
  16 KB          1.40 KB/s           0.03 ms        89.60 P/s
  64 KB          5.73 MB/s           0.05 ms        91.68 P/s
 256 KB         19.20 MB/s           1.42 ms        76.80 P/s
1024 KB         52.32 MB/s           7.75 ms        52.32 P/s * High CPU Usage
4096 KB         74.82 MB/s          37.91 ms        18.71 P/s * High CPU Usage

From these results, the following points can be discovered:

1. When using ActiveMQ, sending messages to a queue yields similar performance to sending messages to a topic with 1 subscriber.

2. Message delay in our own framework is less than 1/10 of that in ActiveMQ in all circumstances.

3. ActiveMQ can only support concurrent data communication up to about 6 MB/s in total, which is far less than 170 MB/s maximum throughput in our own framework.

4. Note that ActiveMQ's capacity is insufficient for delivering video streams, which normally consists of 25 MB-level messages per second.

******************** Conclusion ********************

From this study, we see ActiveMQ is aimed at generality rather efficiency. Namely, ActiveMQ can be used in many languages and on many operating systems. In addition, both P/S and P2P communications are supported by ActiveMQ, with various level of reliability enforcement policy. Nonetheless, the quantitative comparison results suggest ActiveMQ's performance in terms of message delay, data throughput and resource consumption level is much poorer than that of our own framework. The most important point is that ActiveMQ's capacity is insufficient for delivery real-time video streams, which would vital in our applications, and hence do not fulfill our requirement. Moreover, the fact that ActiveMQ-CPP is not BUG free (memory leak is detected) and difficulty in configuration of the development environment are additional reasons that why we should favour our own framework over ActiveMQ.

******************** References ********************

[URL 1] JMS Tutorial,
http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/jms_tutorialTOC.html

[URL 2] JMS Tutorial - Basic JMS API Concepts,
http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html#1023437

[URL 3] Configuring ActiveMQ-CPP,
http://activemq.apache.org/cms/configuring.html

[URL 4] CMS API and ActiveMQ-CPP API,
http://activemq.apache.org/cms/api.html

[URL 5] Apache ActiveMQ,
http://activemq.apache.org/

LOG_2008_10_29

In the previous weeks, I have been developing test programmes for producing quatitative comparison results between ActiveMQ and our own framework. Data throughput, message delay and resource consumption levels were the main concerns. In the mean time, I have also read more documentation about ActiveMQ, which are firstly summarised below.

Here are some finding about ActiveMQ from my literature study:

1. ActiveMQ always (at least for ActiveMQ-CPP clients) use TCP to deliver data between clients and the broker. Therefore, it is expected that ActiveMQ's performance, in terms of data throughput and resource consumption, should be worse than that of our own framework's. This is because our framework takes advantage of Shared Memory, which has been prooved to be much more efficient than TCP when all communicating peers are running on the same host.

2. One advantage of ActiveMQ is that it supports various level of reliability gurantee. In the most strict case, all messages would be saved into disk files and thus message lost are effectively avoided even if broker is crashed (or terminated). However, this is also the most inefficient case due to the extra operations incurred. By default, ordered reliable transmission is only guranteed within each single session of the broker. Additionally, if message lost is tolerated in certain circumstance, relaxation can be made by using difference parameter (tag) combinations which in turn yields better performance. Exhaustive evaluation to all parameter combination is virtually impossible. Hence, the default setting, which best fits into our need, is used in all of our tests. Afterall, since we constantly require reliable message delivery, ActiveMQ's added fexibility in this issue is not really that useful to us.

Screen_Shot

In order to get quatitative results, two test programmes have been developed, which use ActiveMQ-CPP and our own framework's SDK, repectively. In both of them, we have implemented a receiver and a publisher. The publisher simply does the following in a worker thread:

/* Pseudo Code */
while(1)
{
 PubishMessage(pBufContent, dwMessageLength);
 Sleep(10u);
}

Here, dwMessageLength is a variable which can be specified by users from the GUI. The published messages are received by the receiver. Several indicators, including data rate, message rate, average delay, are then calculated and displayed.

Test results are shown in the following tables:

1. ActiveMQ

1.1 Send to a Queue

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB             83 KB/s          1.06 ms        83.00 P/s
   4 KB            331 KB/s          1.16 ms        82.75 P/s
  16 KB           1.10 MB/s          3.25 ms        70.40 P/s
  64 KB           2.94 MB/s         11.63 ms        47.04 P/s * High CPU
 256 KB           5.80 MB/s         33.77 ms        23.20 P/s * High CPU
1024 KB           7.28 MB/s        155.30 ms         7.28 P/s * High CPU
4096 KB           5.26 MB/s        988.41 ms         1.14 P/s * High CPU

1.2 Send to a Topic (1 Subscriber)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB             82 KB/s          1.04 ms        82.00 P/s
   4 KB            327 KB/s          1.22 ms        81.75 P/s
  16 KB           1.09 MB/s          3.26 ms        69.76 P/s
  64 KB           2.74 MB/s         11.72 ms        43.84 P/s * High CPU
 256 KB           6.00 MB/s         30.22 ms        24.00 P/s * High CPU
1024 KB           6.40 MB/s        145.28 ms         6.40 P/s * High CPU
4096 KB           5.20 MB/s        727.39 ms         1.30 P/s * High CPU

1.3 Send to a Topic (3 Subscribers)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            75 KB/s           2.00 ms        75.00 P/s
   4 KB           277 KB/s           2.80 ms        69.25 P/s
  16 KB           854 KB/s           7.64 ms        53.38 P/s * High CPU
  64 KB          2.00 MB/s          20.24 ms        32.00 P/s * High CPU
 256 KB          2.72 MB/s          79.31 ms        10.88 P/s * High CPU
1024 KB          3.31 MB/s         288.23 ms         3.31 P/s * High CPU
4096 KB          2.82 MB/s        1392.08 ms         0.71 P/s * High CPU

2. First Example Framework

2.1 Send to a Channel (1 Subscriber)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            93 KB/s           0.02 ms        93.00 P/s
   4 KB           366 KB/s           0.05 ms        91.50 P/s
  16 KB          1.41 MB/s           0.08 ms        90.24 P/s
  64 KB          5.73 MB/s           0.01 ms        91.68 P/s
 256 KB         22.82 MB/s           0.05 ms        91.28 P/s
1024 KB         73.26 MB/s           2.92 ms        73.26 P/s
4096 KB        171.47 MB/s          13.70 ms        42.87 P/s * High CPU

2.2 Send to a Channel (3 Subscribers)

Message Size   Data Rate          Average Delay     Packet Rate

   1 KB            91 KB/s           0.04 ms        91.00 P/s
   4 KB           364 KB/s           0.05 ms        91.00 P/s
  16 KB          1.40 KB/s           0.03 ms        89.60 P/s
  64 KB          5.73 MB/s           0.05 ms        91.68 P/s
 256 KB         19.20 MB/s           1.42 ms        76.80 P/s
1024 KB         52.32 MB/s           7.75 ms        52.32 P/s * High CPU
4096 KB         74.82 MB/s          37.91 ms        18.71 P/s * High CPU

From these results, the following points can be discovered:

1. When using ActiveMQ, sending messages to a queue yields similar performance to sending messages to a topic with 1 subscriber.

2. Message delay in our own framework is less than 1/10 of that in ActiveMQ in all circumstances.

3. ActiveMQ can only support concurrent data communication up to about 6 MB/s in total, which is far less than 170 MB/s maximum throughput of our own framework.

4. Note that ActiveMQ's capacity is insufficient for delivering video streams, which normally consists of 25 MB-level messages per second.

Up till now, the conclusion should be obvious enough. In consideration of the significant performance gap, we have strong reason to favour our own framework over ActiveMQ.

2008/10/16

LOG_2008_10_16

The work continued during these two days. The compilation has succeeded on Tuesday but there is still a problem: the built activemq-cpp.lib is ridiculously large, namely, around 300 MB. This is certainly unacceptable and thus we have to do something. The first idea came into my mind is to build a DLL version of everything: if that activemq-cpp thing must be this large, at least a DLL version would give us much smaller EXEs. So I tried again to see if we can build everything into DLL. Well, this is not a short story but I'll just focus on the result. Luckily, it finally worked and a functional DLL version was produced at last. Better than this, the size of the produced activemq-cpp.dll is at a reasonable level, say, about several MBs. But don't ask me why... Alas, finally this painfully long journey of building the SDK came to an end and I can give a conclusion here.

How to make ActiveMQ and ActiveMQ-CPP work on your own machine.

*Tip* Before starting anything, you should firstly make sure you have sufficient free disk space. To give you an idea, it cost me 1.04 GB on my computer.

1. Download ActiveMQ, ActiveMQ and Apache Portable Runtime (APR). You may also download CppUnit as well, but that is not really required. Among them, both source code package and binary distribution of ActiveMQ are available online. Of course, I would recommend you to use the binrary distribution. For other things, only source code version is available, so you don't have options any more. In addition, because ActiveMQ is built in Java, JDK is required. To run ActiveMQ's provided Java example, something called ANT is also needed.

*Tip* Unless specifically mentioned (like 'to build XXX, you need X.Y.Z version of PPP'), always download the latest official release version of every package mentioned above. Otherwise, you may encounter misterious errors as I had experienced.

2. Alright, so you have everything now, let's begin to make them running. First, install JDK and ANT. JDK has a InstallShield and thus installing it is quit easy. To install ANT, just follow its online mannual, which is not difficult to follow. You just need to decompress the package and set some environment variables. At this moment, you have the basic environment established.

3. To install ActiveMQ, simple decompress the downloaded package and it shoud then work. Nonetheless, it is never a bad idea to toy it a little bit. So, start a cmd, cd into ActiveMQ_Home\bin, and run 'ActiveMQ.bat'. Your firewall may give you a prompt saying something is requesting to access the network, allow it, and you'll see large portion of text flow down that cmd window, which indicates the ActiveMQ broker is running now. Otherwise, you'll see error messages if some error occurs. After starting the borker, start two new cmd windows, cd into ActiveMQ_Home\examples, then execute command 'ant consumer' and 'ant producer' respectively. If things are going well, you'll see messages beeing produced and consumed. To terminate the broker, just use Ctrl+C. There is no 'more graceful' way.

4. If your ActiveMQ does work, you can start to build ActiveMQ-CPP now, which is the real hard piece. First, you need to build APR, which consists of three packages, apr, apr-iconv and apr-util (yes, you have to download all of them). Decompress them into the same parent directory, and name the decompressed folders to 'apr', 'apr-iconv' and 'apr-util'. This is very important as this directory tree will be used in the building process. Now, go to apr-util, you'll see a dsw file called 'aprutil.dsw'. Although there are also dsw files in apr and apr-iconv, the one contained in apr-util subsumes them. Open it, but not with VC6 but VS2005. Because that ActiveMQ-CPP package only provides an VS2005 sln file, you'd better build the APR in VS2005 as well to avoid potential version incompatibility problems. After converting and openning that dsw file, you'll see a lot of projects. you DON'T need to build all of them. Instead, only libapr, libaprionv and libaprutil are required. To build them, set active configuration to ReleaseDLL, right click on libaprutil and choose 'build this project only'. The preset dependency tree will automatically cause libapr, libapriconv and other required components to be built in the same time. The building process may take some time so just be patient. Warnings may be generated but you can safely ignore them. When the building process completes, you'll see Release folders are generated in apr, apr-iconv and apr-util. libapr-1.lib/dll, libapriconv-1.lib/dll and libaprutil-1.lib/dll can then be found in these Release folders. These files, as well as all header files in the Include folders, are all you need to continue your work. You may also want to have a Debug version of them by changing active configuration to DebugDLL and do the whole thing again.

5. At last, the final step is to build the ActiveMQ-CPP. Decompress the downloaded package, go to ActiveMQ-CPP_Home\vs2005-build and click that sln file to open the workspace. 4 projects are presented. Again, you don't neet to build all of them, only activemq-cpp and activemq-cpp-example (the first two projects) are needed. This time, you need to change the project options a little bit before building. First, add apr, apriconv and aprutil's Include directory to the project's 'additinal include directories' setting. Then, make both of these two projects to link against all libs you have generated in step 4. Finally, change active configuration to ReleaseDLL and use the similar trick to sperately build activemq-cpp and activemq-cpp-example. Again, the building process is quite time consuming. The final ouput, namely, activemq-cpp.lib/dll and activemq-cpp-example.exe will be placed in vs2005-build rather than the generated Release folder. To do a test, run the ActiveMQ broker, then start the compiled exe file and you'll see 2000 messages being produced and consumed. Obviously, all dlls we generated so far are required to start that exe.

6. After the building process, you may want to copy all necessary files out to form a 'clean' SDK package. Here is all you need: libapr-1.lib/dll, libapriconv-1.lib/dll, activemq-cpp.lib/dll, Include folders from apr, apr-iconv and apr-utils and all .h files found inside ActiveMQ-CPP_Home\src\main. Note that the folder structure of all these header files should be preserved as it is maybe required by files. This 'clean' SDK is 16.2 MB in size on my computer. And finally, we are done.

After completing the entire building process, I then started to write a small test programme to extract some key figures of ActiveMQ, including its maximum data throughput, message delay and so on. However, since the programme is still under development, I don't have much to say at current stage.

P.S: Why I also need to prepare the Refs? Damn it! Oh, I also need to give Maja an coarse working plan regarding to the framework issue

2008/10/14

LOG_2008_10_14

I continued my evaluation today. First, I tried to make a consistent compilations of all the stuffs (say, all DLL or all LIB). The results show that DLL version can not be created for APR-ICONV and APR-UTIL but 'all LIB configuration' seems working.

Then, I tried to start exploring what ActiveMQ really is. Well, ActiveMQ is HUGE. It is an complete implementation of JMS plus many additional features. ActiveMQ is aimed at generality rather than efficiency. As we can see, ActiveMQ supports multiple platforms (Linux, Windows and Mac) and multiple languages (Java, of course, and C++ through CMS and many others. Well, here is an additional comment about the relationship between CMS and ActiveMQ-CPP: CMS is like JMS, which is just an API specification while ActiveMQ-CPP is the actually implementation, which is similar to J2EE). In addition, it supports both queue-based P2P communication and topic-based P/S communication plus a wide range of configuration parameters for both of them. A comprehensive evaluation of all configuration combinations of ActiveMQ is simply impossible within this short period of time. Thus, during my tests, default values are used for most parameters. Moreover, for obvious reason, only the scenario of Windows + CPP clients is studied.

To begin the story, let us first get a brief view of how ActiveMQ works. ActiveMQ is something known as a messaging middleware. That is to say, it is used to deliver messages between clients, which could be different objects, threads, processes and so on. Two types of communications are supported. First one is called PTP communication. Here, the system maintains several queues, each one belongs to a specific receiver (a client). When there are messages sent to the queue, they will be subsequently dispatched to (in async case) or retrieved by (in sync case) by the receiver. Note that different from other implementations, queues in ActiveMQ are managed by ActiveMQ rather than the receivers, through each queue should relates to only one receiver and hence is logically belonging to it. Consider e-mail as an example here. The second one is P/S based communication, which we are already very familar with. The P/S scenario in ActiveMQ is very similar to that in Fleeble, only 'channels' are now called 'topics' instead. Moreover, message filtering may be applied before messages are being dispatched hence we also see some charactoristics of Psyclone. Interestingly, clients do not have ID (by default) in both cases. In P/S scenario, ID is certainly not a must. Although ID is seemingly important in PTP communication, separating queues from clients makes this requirement not necessary any more.

So, how this whole thing works? Again, like Psyclone, ActiveMQ is implemented as a central server, which is called 'message broker', plus a number of client development SDKs (like CppAIR in Psyclone) for different languages (ActiveMQ-CPP is the one for C++). To make the system runs, developers first need to develop some cliens (mostly as standalone applications), which use the SDK to send or receive (and of course, to process) messages (which are called producers and consumers). Then, we start the broker (simply the one name ActiveMQ) and all the clients, let clients to connect to the broker, creat all topics and queues, make subscriptions and finally the system starts as all communication begin. This is indeed very similar to Psyclone, but some remarkable differences do exist.

1. Static system configuration is not supported: you can not store the system configuration (describing which clients, topics, queues are used and what is the subscription relationship between them) in a file and start the system with a single key stroke.

2. TCP is the only underlying ICP method used by ActiveMQ (Say, it does not take advantage of Shared Memory when clients and the broker are both running on the same computer. Moreover, there is nothing equivalent to 'in-process modules' in Psyclone). Thus, bad performance is expected when dealing with very-high bit-rate data delivery tasks.

Well, I have only stated its dark side so far. But what is the advantage of ActiveMQ? Generality! There are really not too many situations where ActiveMQ can not be used. You can use it in PHP, Java, C++ and so on; on Windows, Linux and / or Mac; on localhost or across intranet / internet; using (different types of) PTP and / or P/S communications; integrating with website or not... Nonetheless, Efficiency seems more important to us and thus this great advantage is not really exicting, is it?

After the conceptual study, I decided to do some real tests. Guess what, its own example didn't work! Messages are indeed posted (can be seen within the web-console) but never get received. That is indeed wierd. I tried different parameter configurations, went through every relevant help-doc and forum post but I was still stuck there. Finally, after hours of frustration, I found the solution: upgrading the ActiveMQ (which I downloaded in March) to a more recent version (or maybe using a older version of other components would also work)... Nobody has left a single clue to rediculous matter. So, this version incompatibily issue (and painfully lack of formal documentation), is perhaps another conpelling reason that why we should not us ActiveMQ...

Now, I finally get the example runs on my machine. I have changed it a little bit to test both PTP communication and P/S one. So far, both of them seem to work as ActiveMQ claimed so. I intended to do more tests to get key figures like latency, throughput, resource consumption level and so on, but it is already this late. So I'll certainly need to allocate another day for this evaluation task. And that is all for today.

P.S: Need to write to KQH regarding to my external references, replying to JD. Also need to post to WTG and SYS, and don't forget to ask the librians about cards before meeting with Maja.

2008/10/13

LOG_2008_10_13

To follow the regulation, my log book starts running today. All articles with a title started by 'LOG' are automatically categorized into the log book. These articles are for my personal reference only and you are not expected to be interested in them. Nonetheless, considering some of my speculations and observations might be useful to others, I decided to make most of the my logs public. Alright, following is the real content.
 
Today, I was continuing to evaluate ActiveMQ. Indeed, ActiveMQ supports many languages. Nonetheless, but for obvious reason I only considered the usage involving C++ programming. Although ActiveMQ is, in essense, an implementation of JMS and primarily supports Java, it is still possible to use it in C++ applications. In order to achieve this, an C++ SDK, which is called ActiveMQ-CPP, is provided. This SDK is similar to the Framework SDK I had developed during my MSc project. Though using it, applications would be able to conveniently exploit the whole ActiveMQ stuff (protocol and its implementation) as a communication middleware.
 
To evaluate the whole thing, we have to firstly set up the environment and a demo system. This is, I am afraid, not a easy task. Doploying ActiveMQ is trivial but ActiveMQ-CPP led to a totally different story. The key is ActiveMQ-CPP only provides source code, which has to be built by ourselves. Adding to this, ActiveMQ-CPP also replies on a number of other SDKs which do not provide compiled binaries either. The dpendency tree is like this:
 
ActiveMQ-CPP
|--Apache Protable Runtime (APR)--apr-util
|--CppUnit                        |--apr
                                  |--apr-iconv
                                     |--apr
 
Lack of documentation and version imcompatibility made the situation even worse. At last, it cost me a whole day only to get all these things compiled! I'll try to make some meaningfull evaluation on these things tomorrow, regarding to their efficiency, resoure consumption level, effectiveness and usability.
 
And here are some other stuffs: 1. Meeting with Maja at 11:00 am on Wednesday; 2. Got to get a library card ASAP; 3. Got to make a schedule to seperate different tasks. Here is the first draft: Weekdays: 8:30~9:30: reading Metro on the tube; 9:30~6:30: focusing on my PhD / RA related tasks; 6:30~7:30: reading books w.r.t. my personal reading plan; 8:30~11:30: focusing on the website development work. Weekend: Sat.: website development and / or outdoor activities; Sun.: PhD / RA research.  This schedule may subject to temporary disruption and further adjustment.
2008/10/6

我的致谢

先说句题外话,今天上午答辩很顺利,老Duncan都说impressive,Maja也终于在good前面加了她很少使用的修饰词,我似乎又可以继续幻想一下MSc with Something了。好了,硕士的事情终于结束了。(不用提醒我Queen's Tower...)

又到了学校正式开学的日子,上午看到很多新学生填表注册,中午的食堂也热闹了起来。看到这些脸上写满了好奇和憧憬的新面孔,不由的想到一年前的自己。一年的时间过的果然很快。五门专业课,一门论文学习课,两个小项目,一个毕业设计,这就是硕士课程的全部。虽然项目的结果还不知道('nonetheless, it is expected to get a high mark' - said Maja),但是考试考到Top of Class,还‘撞大运’的拿到了一个带Funding的读PhD的机会,这一年怎么着也算是小成功了。

虽然没写到论文的Acknowledgement里,但是我还真想额外谢谢一些人,那些从中学以来在各种场合鄙视我的人们。对,我感谢你们,感谢你们的鄙视。

首先感谢少年班长期以来鄙视我的某些老师们。看吧,多次当着全班的面鄙视我在家不跟老妈练英语(我就是觉得这样很傻难道也有错吗?)并断言我一定混不出名堂的汪老师,老子现在Imperial College London混的比硕士班上绝大多数Home Students还牛那么一点点。看吧,天天中午把我叫到办公室边吃饭边骂的徐老师,老子在书写、古文和修辞方面就是没天赋,但在浙大近十万字的本科毕业论文却是全系最高分,您还能说我‘没有基本的使用语言的能力’吗?看吧,当年在高考前我心理压力最大的时期还鄙视我数学上不了120的张老师,对,我高考数学确实因为您这一句话紧张到发挥失常只考了119,但是老子现在也是Department of Computing天天玩N维向量的博士生了。看吧,当年鄙视我‘完全没有钻研问题的学术精神’的程老师,老子在浙大毕业的时候混到了个‘学术之星’,在中科院工作和在Imperial College读硕士的时候也被认为有很强的Academic Potential,您的慧眼是不是也有看错的时候?程老师啊,当年您以黑箱操作的方式在未经选拔的情况下让某些人获得宝贵的机会然后再不断的用他们的成功事例来鄙视我,您不觉得这样很恶心吗?最近几年,每每在梦中又见到一脸鄙视指着鼻子断言我没前途的诸位恩师们并尖叫着从汗湿的床上惊醒时,我如何能忘却这个畸形的少年班教育!王老师啊,您还建议过我老妈带我去看心理医生?您还真是有先见之明啊,这可都是您们的成就啊!然而,赵老师,(化学)王老师,我也要感谢您们,真心的感谢您们。感谢您们能够公平的对待我,能够就事论事的批评或表扬,能够在我成绩差的时候给我以批评和鼓励而不是轻蔑的眼光。如同黑暗中的烛火,没有您们,我将消沉,而今天取得的一切都将成为不可能。

我还要感谢大学里面某些唯成绩论的诸位主管学生工作的老师们。保研曾是我大学时的梦想。04年四月的某个上午,“你的平均分怎么样?”“大概前三分之一吧”“三分之一?你回去吧,我很忙”,短短的三句话,几年来的努力和梦想在一瞬间幻灭。我跑回寝室大哭了一场。最近十年来唯一的一场。在这之前,曾有过两个老师跟我说过希望我在他们那里读研。就在这件事发生一周后,SRTP项目答辩上还有一位控制系的老师对我的工作感兴趣并希望我去跟他谈谈。在浙大的时候,几乎每一位带过我的导师都跟我说过希望我能在他/她手下继续读研,但直到今天,在一个距离浙江大学数万公里之遥的地方,这样的话才真正得到了兑现。这一切仅仅是因为我惨不忍睹的政治类课程成绩和主观学生工作的老师们的“我很忙”。竟然仅仅是一句“我很忙”!然而,塞翁失马,焉知非福,只此一句足以。曾几何时,我是一个被浙江大学研究生院抛弃的本科毕业生,我不会——永远不会——忘记这一点。

我还要谢很多人,更多人,我的家人,朋友,绝大多数同学和恩师,以及很多很多其它的人。那些都是正常的致谢,当然。即使是最阴霾天气,天空也依然被阳光照亮。然而这样的致谢词我已经在不同的地方写过很多次,这里便不在赘述了。

从93年初次走进课堂,一路过来已是十五年,就此致谢,告一段落。今天,在前人所未及之地,我的探索之旅正式开始。

2008/10/2

祸兮?福兮?

Hans Rausing奖学金的结果出来了,没拿到。早上收到一封信,写的叫个经典啊:“介于所有候选人都很牛,我们确实很难做一个决定。尽管如此,我现在已经可以公布,奖学金将颁发给生物工程系的候选人”,绝的在下面一句:“如果因为任何原因使得他们不能接受,计算机系的候选人将作为后备”。呵呵,感觉好像是抽奖抽到“恭喜您,就差一点点”一样,这要是写个“谢谢惠顾”不是大家心理上都能好过点么-__-b 

只好给老板做Part Time RA赚学费了。不过说起来这个工资(25~28K/Annual)说不定还比奖学金多呢。虽然少了一个很好看的Resume Builder,研究方向又被项目框死了,但是横竖还是能接着拿funding读PhD,我也就不多抱怨什么了。

 
2008/10/1

英国的用词习惯和生活点滴(1)

我也写点无聊的东西。这都是我日常生活中自己总结出来的,没啥参考资料,难免有错,大家随便看看就得了。

1.地铁:在伦敦这个地方过日子,没有地铁绝对寸步难行。地铁的说法英语课本上好像有,叫Subway。但是在英国,Subway一般指的是人行地下通道。伦敦地铁站的标志上写的都是Underground。还有一种更大众的说法是Tube。比如地铁图就叫Tube Map,地铁站叫Tube Station,等等。我记得在美国地铁也不叫Subway,至少在华盛顿和纽约地铁站标的都是Metro。所以我也挺奇怪为什么当初英语课本上教的是个大家都不用的词。

2.咖啡:熬夜赶项目,咖啡是必不可少的‘生产要素’之一。但是英国人喝咖啡就跟咱们喝茶一样,有很多讲究。就跟咱们把茶叶分成龙井、毛尖、香片等种类一样,他们也给不同类型的咖啡起了很多名字。首先说说冲调好的咖啡。在国内过的比较滋润,经常去Starbucks的同志们估计对这块是很熟悉了,不过为了完整我还是说一下吧。一般来说,常见的咖啡冲调方法有Espresso, Cappuchino, Latte, Mocha和American Coffee(不确定拼写,反正都是些外来词,音对就成了)这五种。去咖啡店买的时候您就不能只说要Coffee了,得说明到底要的是哪种。Espresso: 浓缩咖啡,就是加水很少所以巨浓的咖啡,不加糖和奶。因为Espresso浓,所以相应的用的杯子也很小,跟国内的喝白酒的小杯差不多大。Cappuchino:奶沫咖啡:下面是白咖啡(White Coffe12e,加奶的咖啡,记得这个英语课本里也有吧。对应的,不加奶的就是Black Coffee),上面一层奶沫。这种咖啡是最常见的,喝的时候得有点本事才能把奶沫一起喝下去,您就自己摸索吧。Latte:奶很多的白咖啡。Mocha:加了巧克力粉的白咖啡。American Coffee,最‘没品’的东西,其实就是清咖啡。这里还得说一句,一般那些咖啡在上的时候都没有糖,得自己加,但是Mocha例外。因为巧克力粉是甜的,所以Mocha本身就很甜,如果再加糖就难喝了。笔者自己就犯过这个错误。虽然咖啡店在英国不像在中国那么奢侈(相对来说),但是去咖啡店买还是挺贵的,而且也不是哪都有店。在学校要喝咖啡一般都是从自动售卖机(Vending Machine)那里买。其实自动售卖机出来的咖啡不见得差。比如有些机器是用磨碎的咖啡豆冲泡的,味道和店里卖的差不多。

不管是店里卖的还是自动售货机,都比自己冲泡要贵不少,所以买包咖啡放在家里或实验室是很有必要。这时候就得注意看袋子上写的东西了。首先是种类。整粒的咖啡豆一看样子就能看出来,但是Grounded Coffee和Instant Coffee看上去就差不多了,都是粉末,很容易搞混。Grounded Coffee是磨碎的咖啡豆,不能全部溶解,冲完之后必须用专门的滤纸把渣滓滤出来,还挺麻烦的。要省事的话就买Instant Coffee吧,直接冲完了就能喝。另外还要看咖啡的烘焙程度。一般分Brown,Medium Roasted和Dark Roasted三种。其中Dark Roasted是烘的最‘干’的,颜色也最深。如果买的不是用很好的原料做的咖啡(那样的咱也买不起),最好买Dark Roasted,否则会有较重的酸味。另外,买的时候还得特别注意看一下是不是脱咖啡因的(Decaf)。最后一点,有时候咖啡的包装上可能会印着Fair Trade,这跟咖啡本身没关系。Fair Trade是英国民间组织搞的一个项目,旨在保证不以掠夺式的低价购进原材料,并同时利用部分利润对原产地提供一些包括卫生、教育和基础设施建设等方面在内的援助。不过一般来说Fair Trade的东西都是比较差的(否则也就不存在‘掠夺式的低价’这种问题了),同时也都比较便宜。
2008/7/25

死了@_@

老板说,这一切都很好,但是没有最终系统的Demo是绝对不行的……啊啊啊,没时间了……