随笔（2014.7）

      1. DSQL, ESQL, PSQL

      DSQL概念不大确定，（DSQL语言难道是在iSQL工具下运行的么）ESQL可以参考百度百科，简单来说是可以在其他高级语言例如C语言中直接写SQL语句，然后用另外一个工具去编译这个C语言，听着就麻烦，大型工程编译岂不是很麻烦，一般是直接用特定数据库提供的接口去执行特定的语句。PSQL应该就是存储过程中的，还有一个iSQL，是用工具直接访问数据库时候的一个工具。也可以理解为ESQL、PSQL、ISQL（DSQL?)都是一种特定情况下使用语言，有着不同的编译器。

 

Description: Executes a block of PSQL code as if it were a stored procedure, optionally with input and output parameters and variable declarations. This allows the user to perform “on-the-fly” PSQL within a DSQL context.

      这是firebird guid这说明execute block的作用，可以在“DSQL context”下运行一个正在传输来过的PSQL语句，这个DSQL context不就是用iSQL工具执行的么，所以推断这个DSQL就是在iSQL工具中也就是“DSQL context”中的语言。

 

      set term ; ^ 的解释，参考：http://www.cnblogs.com/fyen/archive/2011/05/10/2042726.html
“在存储过程中，除了Create Procedure,As,Begin…End语句之外，任何其他语句末尾都要添加分号结束。因此，如果你使用isql创建存储过程，你必须另外定义其它的符号来代表创建存储过程的结束，通常使用set term语句完成。比如，在创建存储过程之前，使用set term !! ;把！！作为分号来表示存储过程创建的结束，在创建存储过程的语句之后，再用set term ; !!恢复分号的作用。”

      为什么这样呢，因为在isql中是“面向行”的，也就是一行一行的执行，其实也就是找“;”去执行，但是存储过程创建有很多行组成一个真正的“行”，面向对象的角度来说就是聚合了下，所以需要把别的符号定义成“;”，也就是说用另外一个“启动执行”标志。

 

      2. sip为不定长协议，不定长协议解析可能会慢但是有效利用带宽。sip可读的优点数据的透明和便于排查问题，扩展性强，但是数据冗余。
二进制协议： C/S要共享同样的数据结构，有编译依赖关系，或者代码copy,  可用于内部通信协议，或者出于保密原因的通信鞋议。比较高效，cpu不用解析文本，带宽少。
总的来说，这就是一个平衡的过程。如果消息体不是很小（比如每次只传一个字节的消息就很小了），那么采用文本协议还是值得的。毕竟文本协议简单，好扩展，利于调试。

 

      3. base64编码会膨胀30%，编码中没有'\0'，编码用255个字符。

 

      4. 协议中起始字符和结束字符的作用，既然协议都有length + content的方式来搞，那么结束字符，起始字符有什么用呢？他们的存在可以在长度与内容不匹配的时候丢掉坏包，从而不影响后面的包的传输。这个和加入应用层的crc校验是一个道理，一般客户端会断开重连。

 

      5. 解耦处理方法，为了防止资源需求变动，不同业务需要不同资源，可以对资源进行统一管理，放入一个资源队列，单独线程分发，这样上层业务改变，只要变动处理策略。以前是一个资源生成后发送到“应该”需要的地方，但是需求变化可能会有不同。解耦方法是把所有资源统一管理起来，这样可以以后变更容易实现，多了一层资源聚合的步骤。

 

      6. 订阅方法的局限性：1）处理上可能有歧义，例如一条协议被两个地方订阅，那么中心分发的时候会给两个地方发送，这样就会回复两条协议，可能业务上只需要一条协议应答。2）分布式的时候，如果一条协议处理在同一个服务器很吃力，那么分布式的时候如果只是通过这样简单的订阅可能重复处理。

 

      7. 提供代理服务器所需要使用的本地路由策略，本地路由策略是代理必须所要经过的路由集合。

 

      8. 设计的时候可能有多余的流程与代码，只是为了实现方便统一，可能以一个对话框作为一个对象，而没有细化，比如对话框有几个tab，在修改一个tab时候，其他tab保存协议也一起发送。开发效率高，错误少，但是协议有冗余。

 

      9. 为什么选择firebird？首先是小，跨平台，有存储过程等等。对其他接触不多，但是从网上看比Access、SQLite性能更好，更简单。

 

      10. 设备删除的时候先数据库，在通知各个服务器缓存，还是先通知缓存，再删除数据库？系统中是先删除数据库，再通知，删除数据库失败的可能性大。其实这个是一个有争议的问题，处理方法一是先删除数据库，再删除缓存失败后反复发送消息删除，一直到缓存删除，或者超时再回复删除请求，但是这样应答时间会挺长，而且如果一直删除失败数据库要不要rollback？

 

      11. 如果数据传输慢，多开几个同样的进程使用不同端口会有速度提高么？应该不会这个应该和网卡有关系，与端口多少没有关系，端口只是一个操作系统逻辑上的概念，真正传输的物理上的限制是带宽与网卡。

 

      12.历史数据查询时候，查询一个设备的时候，返回结果每个数据点都有设备名字、id、等等冗余的字段，不仅带宽浪费，而且解析时候速度慢，对资源消耗大。可以优化返回结果，去除冗余字段；还可以在xml结果中直接用二进制协议编码方式，进一步减少所用空间，提高解析效率，但是需要在定义解析规则。

 

      13. 历史数据查询返回协议数据量大也可以不通过中心服务器，给中心减少点压力，中心可以做的跟cpu似的，数据不一定经过寄存器才到内存，可以从硬盘直接到内存（DMA）。可以与视频流流程类似，历史数据查询结果可以直接给客户端，中心只是一个控制作用，告诉设备接入服务器该把协议结果返回到哪里就可以了。

 

      14.中心很多设备不必加载，只加载有路由信息的设备即可，中心相当于路由功能，客户端显示设备列表是从数据库自己加载的，在增删改查的时候，设备应该有带路由的父设备。

 

      15.visitor可以解决设备访问的问题，把遍历访问方法的职责核心类不做，只是提供一个开发的visitor方法，visitor方法也是逐个判断是否是自己需要的对象，访问或者保存。这个模式感觉作用不大，核心类完全可以把自己的要访问的东西提供一个类似迭代器的访问方法，返回一个count，用一个GetObj（Offset）的方法来遍历。

 

      16. 向上对接，如果是站端对接，一个变电站对接，可以做成轻量级的东西，和das放在一起，这样如果所有设备都通过das接入，用通过das向上对接，那么可以直接去das上下文中获取数据，do操作等。如果是整个系统向上对接，例如一个地市的变电站主站向一个省站的变电站主站对接，可以单做一个向上对接的服务器。

 

      17. SimpleNetMsg作用可以提供一种复制部分NetMsg的Response方法，减少不必要的拷贝，关键是这样可以让部分逻辑只关注NetMsg的Response，而看不见resquest部分。

 

      18. Overflow occurred during data type conversion.
conversion error from string "". firebird 报的错误，问题就是那个时间的类型，不能用‘’空去传进去，必须是2014-07-10 00:00:00这种格式

 

      19. missing ';' before 'namespace' 类的最后没有加分号，太坑了什么编译器

 

      20. SimpleNetmsg m_msg; 
 CProtocolData proData;
 proData.Parse(m_msg->GetXMLData(), m_msg->GetXMLDataSize());
 CElement ele = proData.GetElement("Message/IE_ZXPIS_DEVICE_QUERY_BY_DAS");
 ele.SetAttribute()并没有起到作用
 首先有一个const修饰，这就导致了肯定是没法修改的，然后再parse后proData其实是用char *的一个字符串构造了proData中的元素树，SetAttribute方法其实只是对CProtocolData中结构元素树改变，而m_msg中->GetXMLData()是一个char*，两个完全不一样的结构体，肯定是不会有同步什么的了。