在湖南人文科技学院imagelife同学的邀请和帮助下,通过分析wireshark的抓包编写出来的的认证客户端。由于之前有了写ZDClient的经验,似乎上手比较快…… 联想的协议似乎更简单,没有神州那样在报文里面附上一大堆ip阿网关阿DNS这些恶作剧的东西,所以直接拿了ZDC的代码来删删删,然后根据他们整理出来的一份协议的简单分析,已大概整理出了雏形。 项目主页:http://code.google.com/p/zlevoclient/ 欢迎大家帮忙测试使用!
神州数码客户端ZDClient升级到0.4,完善DHCP模式的认证 经过跟武汉大学的michel同学不断的折腾和测试,终于搞清楚他们学校动态DHCP的流程了,“Windows启动后,提示本地连接受限”,到认证后才开始获取IP,这才是动态DHCP模式,所以使用ZDClient的dhcp后,需要运行系统的DHCP客户端重新获取一次IP(通常是dhclient),这一点功能在启动脚本dhcp_zdc_run.sh内已经包含。 现在在Google Code上面的项目已经正式启动,终于用上svn的服务器了,不用把桌面搞的一团糟。 大家可从项目主页下载最新的源码包:http://code.google.com/p/zdcclient/ 之前的网盘链接已经作废。 特别感谢一下刘群同学的关注,给我编译i386的binary,我似乎终于搞定在amd64使用32位的包了!
0.3更新-客户端默认版本号更新为3.5.04.1013fk-修正对SUCCESS数据包的识别-后台运行改为在认证成功后主程序返回-根据状态区分用户名、用户配置信息错误与密码错误的两种提示-在接收和发送Keep Alive报文时提示当前线程的pid-改善pcap的抓包过滤器,只抓发往本机的报文 在姚老大的群里面找到武汉大学的同学micheal帮忙测试了ZDClient,昨天晚上把他们的官方客户端的数据包抓了过来看,原来版本是3.5.04.1013fk,比我们的新!不过奇怪的是广州大学的认证服务器除了用户名密码别的似乎什么都不认证,我怎么乱填都能认证成功 = .= 顺便提醒一下武大的同学,记得在zdcrun里面加上--dhcp参数…… 大家可从项目主页下载最新的源码包:http://code.google.com/p/zdcclient/
今年年初的时候加入了iptux的项目,这是个Unix平台下的“飞鸽传书”,虽然一开始只是关心一下,后来给它写了英文版文档、整理了资料,以及对软件界面的一些调整,原来的作者Jally居然把我也设成Project Owner之一了。 据说程序员总有完美主义的倾向,一开始我还没给iptux写多少行代码,Jally就在邮件里面给我大说代码风格代码风格,很郁闷,我很想对他说,我是看你的代码风格那么乱,我才用了“乱风格”的。iptux是使用C++为架构,但是使用基于C的GTK为底层库,C和C++的代码风格是相当不同的,两者一旦混合起来就很难说什么固定风格了(不然人家基于C++的gtkmm要来干吗),不过我也在邮件里面给他挑骨头,几番下来他说代码先交给我来写了。不过两个月下来我也没再怎么给iptux写过多少行代码,上星期iptux的邮件列表突然热闹了一下,想到之前要实现“URL识别并可点击”的功能,就用了一个晚上加入了400多行代码来实现,惊叹的是原来实现鼠标指到一个链接变成手势那样的事情居然那么复杂,不过还好,gtk-demo里面有现成的例子,这400多行代码有不少是从demo里面抄的。 说程序员是完美主义者,且看看Gtk的邮件列表的人,我发邮件去问了一个关于Glib的链表内存释放的问题,却引来一堆回复,后面的人针对有的人表达得的不完美批一通,毫不客气的说,比之前我和jally的邮件有过之余无不及: 我的问题Why there's still ONE element left after g_slist_free () ?已经很完善的解释:我的总结:围观的群众:English Lession
上学期混混沌沌学完《数据库原理》,感觉除了会写几条SQL外没什么收获,至于DBMS的工作原理那些,在《操作系统》完全都有,但教数据库的老师不仅不知道这些联系,一丁点数据库技术前沿的信息也没“透露”过。这个学期的数据库课程设计,我用了一个通宵把基本要求的一个“图书管理系统”做完,用了pygtk作为界面和SQLite作为数据源。不过课程设计是需要搞文档的,一个字,很烦,在Google上面用“数据库课程 学生作品”搜出来了某某学校网页上面的作品,把别人的文档重新组合一下,配上我程序的插图,yeah,完工。 Python虽然在这几年逐渐流行,但是它很历史悠久(1990),一直以简洁和功能强大著称,比如内建对SQLite的支持。SQLite是“文件式数据库系统”,也是近年来发展很快的数据库系统之一,比如Firefox等软件都使用其作为后台数据的管理。SQLite秉承了Python弱类型的特点(呃,其实Python和SQLite没什么关系的,说不上秉承...),创建表的时候那些类型你可以天花龙凤地写,插入数据时更是“没王管”。这个LibiaryManager很可能是大家能在Google上能找到的技术最潮的数据库设计作业了。 为了给老师验收,pygtk在Windows下运行的环境也要设置下,不过还好,在pygtk的FTP上可以找到很新的win32版本(主页上面的链接很旧...),而且pygtk、pygobject、pycairo是单独打包的,缺一无法运行(= .=)。 程序中基本使用Treeview来处理输入和显示,不过后来感觉Treeview对录入数据很不方便。 当然啦,这次作业来自网络,当然还要回到网络中去,不保留任何版权,从这里下载:http://code.google.com/p/ptcoding/source/browse/trunk/LIBManager/
Warning: unable to set property `editable' of type `gboolean' from value of type `gchararray' 做GTK编程的时候,使用TreeView控件时出现这个警告,也就是无法使单元格变为“editable”,原因出在这里: column = gtk.TreeViewColumn(columName[columnNum], renderer, editable=True) 原理解TreeViewColumn的构造函数接受的参数里面可以接受设置Cellrenderer的属性,就直接给editable设True,于是就得到以上警告。 换用add_attribute、set_attributes,均是如此。 Google上搜到同样错误警告,但是他的原因是设错值类型,我明明设了True啊…… 自己观察pygtk-demo的代码和手册,突然发现在构造函数里面给出的属性设置值不应该是直接的值,而是对应Model里面的相应column的值!看手册的描述: Zero or more attribute=column pairs may be added to specify from which tree model column to retrieve the attribute value. 呃,果然是看手册时候大意了,这么多年来还是让英语介词搞的晕头转向。如果在构造函数里面设True这个值,就会被解析为1,去对应Model里面第二栏的类型,是字符串的gchararray,当然对不上了。 解决办法是renderer.set_property("editable", True),调用继承自GObject的set_property方法来设置对象属性。
最近完成学校《操作系统》课程的试验报告,其中的题目是用程序实现银行家算法。什么是银行家算法,这里就不详提了,具体参看Wikipedia-zh。 Wikipedia的页面里面有整个银行家算法的伪代码,加起来只有12行,很清晰地表达出整个算法的思想,然而如果你到别的地方看看一些具体的银行家算法实现,往往会被吓一跳(可以看看百度百科的词条)。 银行家算法本来并不复杂,只是其运算涉及向量、集合,实现起来还是花要一点功夫。我使用C++来实现银行家算法,为了实现和伪代码描述尽可能接近,重载对象的运算符等,最后整个算法的实现和伪代码没太大差别,也就20行的样子。 伪代码 while (P != ∅) { found = FALSE; foreach (p ∈ P) { if (Mp − Cp ≤ A) { A = A + Cp ; P = P − {p}; found = TRUE; } } if (! found) return FAIL; } return OK; C++代码 1 2 3 4 5 6 [...]
使用ibus时间长了,常常突然发现有些本来常驻的首选或者常用字词突然掉到后面,甚至到了第二页,并不是被其他词挤掉,而是可能ibus的用户数据库出现错乱了。 不知道这是ibus程序的bug,还是ibus所用的SQLite数据库系统本身的问题,本来当用户输入一个拼音,ibus从用户数据库里面提出对应字的用户输入频数,决定字词的位置;如果用户第一次选择输入某个字,那么该字的记录就添加到用户数据库中,下次输入时便以此记录来提前该字的位置。理论上,在用户数据库里面一个词条的记录最多只能出现一次(多音字算多个字),然而,在实际的使用中,有时不知什么原因,某个本来常用的字被当作第一次输入再次加入到数据库当中,下次输入时,该字便作为低频字来排序,导致位置变得很后,带来不少不便。 这个Python脚本就是把这样的词条找出来,并把后来加入的记录删掉,把词条频数还原。 脚本下载:http://code.google.com/p/ptcoding/source/browse/trunk/ibus_fix (svn目录内的ibux_db_fix.py,其他的两个是测试脚本) 程序功能: 自动备份用户词库 检出用户数据库中出现了两次,但不是多音字词的词条 将后加入的词条删除 检出错词的SQL: SELECT * FROM py_phrase WHERE phrase IN (SELECT phrase FROM py_phrase GROUP BY phrase HAVING COUNT(*) = 2) 尚存缺陷: 如果同一个词条的记录出现了3次或以上,程序不能鉴别(极少可能出现,可修改脚本内的SQL语句来查询出来) 如果一个字本身是多音字,其中一个音节出现了上述情况,程序不能鉴别(貌似概率也挺低的) 如果两个记录中的用户输入频数相同,两条记录都会被删掉(倒不是坏事,影响不大) Python源码:
Page optimized by WP Minify WordPress Plugin