项目标识: LC-屏幕校正, SR-StarRiver路灯控制, SE-SkyEye无线监控
20140801
- SR: 功能测试
- SR: 终端设备查询增加一个任务同时查询多个设备的能力
20140804
- SR: 系统忙时跳过控制器自动状态查询。
- SR: 自动查询设备状态功能在各控制器独立并行处理。
20140805
- ownCloud: 独立服务器上安装系统
- Ubuntu 14.04 LTS x64 on RAID1 (2*1TB)
- ownCloud data on RAID6(8*1TB)
- 2 1TB hot spares
- ownCloud: 安装、配置 ownCloud
20140806
- SR: 更改配置,支持升级安装
- SR: User manual 英文版
20140807
- SR: 功能测试
- 发现一个新的 Windows XP 的限制:系统事件日志限制在512k,且默认只覆写7天前的旧记录。当7天内的记录写满512k会导致系统服务无法启动。
- 这个问题在 Windows 7 上不存在,默认配置就可以不断覆写旧记录。
20140808
- SR: 修正v0.2-alpha安装程序中错误的
config.ini
服务器地址默认值 - SR: 解决唐德测试系统连不上数据库的问题
- SR: 将昨天系统事件日志满导致 StarRiver Server 无法启动的解决办法加到用户手册中
20140811
- LC: 遍历单个像素发光范围内的点
- SR: 讨论响应帧回复出错后的处理办法
20140812
- GitLab: v7.0.0 -> v7.1.1
- 准备项目工具使用介绍slides
20140813
- 善用工具,提高效率
- VS2013中Git的使用简介
- SourceTree中checkout以前的版本
20140814
- SR: 服务器重启自身功能
- SR: 控制器 WorkMode 增加默认值
0xFF
表示尚未读取过实际值 - ownCloud: 配置静态路由,指定内网各个网段的网关为
192.168.0.1
- SR: 性能测试
- 单控制器200盏灯,初始化总共用时10秒。包含2(清空设备、添加设备)+200*3(清空组、设置组、设置初始属性)=602个任务。这类简单任务的处理能力大约为50~60TPS。
- SR: MySQL性能测试(复杂操作的transaction)
- ESXi上的虚拟机:78.02 tps
- 我的开发机:46.25 tps
- 唐德用于测试的笔记本:21.60 tps
- 外部条件不变的情况下,StarRiver客户端+服务端的性能是线性的,目前的瓶颈就在数据库上。论据:实测初始化设备操作能达到60tps左右,对比数据库的78tps,可知大部分时间用在了数据库操作上
20140815
- SR: 数据库文档更新
- SR: (与曾磊、唐德)改进方向讨论。
- 接下来首先借助日志分析大量设备状态查询的耗时在各个步骤的比例,找到瓶颈,再设法提速。
- 客户端计划修改为批量添加调光、查询任务至数据库,以减少逐个添加大量任务的交互方式下,由于数据库定时查询间隔累积出的延迟。
- 服务端如有必要的话,增加一条指令用于清空控制器下当前未执行的任务队列。
- ownCloud: 修正路由表设置,解决192.168.4.36无法ping通服务器的问题。
- ownCloud: 192.168.4.36上IE6访问不了ownCloud,改用Firefox可以正常访问。
- 我推测是因为IE6最长只支持128位的Key,而现在的SSL Key大多是2K和4K长。
20140818
- SR: 讨论用户任务执行出错后的处理
- SR: 借助日志分析大量设备调光、状态查询的耗时在各个步骤的比例
- 发现任务、发送数据帧、接收数据帧在1秒内完成
- 更新数据库的SQL语句执行一直排队了近4分钟才执行
- 优化通信程序设计,将控制器查询任务的数据库交互次数(不包括从缓存返回的查询次数)从10次降至3次;设备查询任务的交互次数从19次降至3次。
- ESXi: (与赵工)新建虚拟机安装Windows Server 2008 R2 Standard x64
- 具体的辅域控配置迁移待刘兆亮操作
20140819
- 用icu探测字符串编码
- 用icu转换字符编码 UTF8 <=> UTF16
- SR: 稳定性测试
- SR: 解决设置调光模式成功后查询到旧模式的问题
20140820
- LC: 像素亮度计算
20140821
- SR: 数据库建更详细的索引,降低查询时间
- SR: 新需求讨论
- 加密:我们认为目前的协议选择AES加密(块加密)不合适,这个应用下更适合选择流加密算法(如RC4)。原因如下:
- 协议里有一条命令,从控制中心下发AES密钥至控制器。协议还规定加密范围仅限于帧的
数据部分
,帧起始符
至数据长度
以及校验码
、帧结束符
不加密。 - 注意:LCP-SH-D协议中没有转义的过程。
- 启用加密后,
长度
描述的还是未加密的数据长度,但加密后数据长度发生变化,帧解析过程可能产生歧义。(不可能假设加密后的数据在大于等于长度
的位置上不为0x55
。这种情形一般会被解析成一个错误的帧,要是碰巧还能校验通过被执行了,那就……) - 只有用流加密算法,才可以保证加密前后的数据长度不变,保持现有的解析过程依旧有效。
- 协议里有一条命令,从控制中心下发AES密钥至控制器。协议还规定加密范围仅限于帧的
- 同步控制
- 这个是唐德接到的需求变更。现在控制器的行为是异步的:收到控制命令,记下任务,返回OK,后台慢慢做任务。新需求是,等任务(如调光)完成,才返回OK,为了在返回时看到灯的实际状态。
- 唐德说控制器对单灯的操作,当前大约需要6秒。
- 我们认为控制过程不应该等待单灯的响应。不管控制器是否立即返回
OK
,实际操作执行完毕都需要N*6
秒左右。由于有后台定时查询功能,控制器立即返回后,在N*6+查询间隔
秒内,即可读到执行后的状态,差距最多为一个查询间隔。付出的代价却是N*6
秒的阻塞,控制器和用户都无法执行别的操作。
- BS 架构的用户界面
- 也就是曾磊的程序功能做成网页版, 同样通过数据库与通信程序交互。
- 需求可以满足。网页版还能让很多功能的实现变简单,比如历史查询、图标绘制等。
- 这个具体是否实现、什么时候实现看曾磊的安排了。
- 加密:我们认为目前的协议选择AES加密(块加密)不合适,这个应用下更适合选择流加密算法(如RC4)。原因如下:
20140822
- 整理对LCP-SH-D协议AES加密部分的两点疑义给李应启,需要细化协议描述。
- 用Crypto++尝试AES加密、解密
- 做了ECB和CFB两种模式的加解密
- 协助曾磊和沈工尝试在Windows XP下使用Git。
20140825
- 熟悉Crypto++使用
- 更新笔记本上的StarRiver用于demo
- StarRiver界面设计讨论
20140826
- LC: 像素亮度计算
- SR: 试用时间限制
20140827
- SR: 更新文档,统一组件名称。
- 提供两台Windows系统的虚拟机供曾磊调试3G应用。
- SR: 试用时间限制
- 安装后首次运行记录时间戳T
- 此后服务启动前首先检查当前时间,若当前时间在T之前或T之后30天,则进入过期状态
- 过期状态不再检查当前时间,不论改到什么时间,依旧为已过期状态
目前没有提供更新license永久有效的功能。可以通过提供一个N年后到期的license变相达到这个目的。
对具体机器或者用户的注册机制比目前这个初级限制要复杂不少,如果有需求的话,需要一段时间来做。目前我尚未找到公开的文章具体介绍这类机制的实现方法,仅有一些公钥认证原理上的解释,距离技术上的实现还挺远的。
20140828
- LC: 像素亮度计算
20140829
- 实现ownCloud共享以WebDAV方式映射为Windows盘符
- LC: 像素亮度计算