C++博客-我自闲庭信步,悠然自得,不亦乐乎.-随笔分类-Server

再次重写了XML解析模块

HuYi — Fri, 28 Apr 2006 16:36:00 GMT

最开始用的libxml2，linux上倒是方便，但为了在win上使用这个，需要编译一大堆附加库，还要带上大家伙，本来是为了图方便，没想到更加的麻烦，而且在实际使用中，也并不顺手。鉴于此，我放弃了libxml2。

之后又瞄准了arabica，一个针对C＋＋的解析库，严格的说是一组包装类，在底层还是靠expat等其他引擎来解析xml的。这回看起来爽多了，不用担心平台问题了。在实际使用中，引了一大堆的头文件，继承了一堆父类，虽然类责任更加明确了，但这确实不是我所喜欢的方式，简单就是最好，这是我所推崇的。尽管如此，为了图便宜，我还是没有放弃采用arabica，甚至为它禁用了一个原先工作正常，但现在有冲突的标准lib文件（可恶的LN2005错误），但最后还是发现，arabica在一些地方并不完善，文档也不全面，很费了一番周折才work起来不说，出了问题还要搞半天，我只是想要简单的解析功能，实在不想去研究透澈一个第三方库。

一气之下，决定自己封装expat，花了1个多小时，整个世界清静了，现在一起看起来那么干爽，一切都回归到预想与控制中。功能可能不如第三方库全面，但也足够了，而且需要的话可以再添加。长叹一口气，主席说过，自己动手，丰衣足食。

至于再高一层，我并没有像wildfire那样，用pull的方式，边执行逻辑，边解析。
我希望能得到pull模型给程序结构带来的一些好处，但又不想把解析xml的动作带到整个程序中，最好能在一处解析完，但又能继续使用pull模型。为此，设计了XmlBlock对象的一个队列结构来模拟pull操作，也受到了ACE中ACE_Message_Block机制的一些影响。
后来又仔细想了想，其实内部利用std::list就可以了，做一个wrapper，公布一个一次性的ForwardIterator，就可以模拟出Stream操作的特点了，现在还没有必要做的像ACE_Message_Block那样精。

具体做法，今后会写进文档中。

HuYi 2006-04-29 00:36 发表评论

TIM中网络模型变更

HuYi — Mon, 27 Mar 2006 14:54:00 GMT

一直都隐隐约约的感觉TIM的网络模型还是有点问题，但却总说不出具体问题来。时不时就会想起这个事，今天在车上，终于恍然大悟。
也许是受wildfire和jabberd2的影响太深了（特别是wildfire），TIM中网络和业务处理的联系过于紧密，从套接口读到数据流后，马上就进入XML的PullParser分析阶段，虽然之后有刻意的分离网络操作和业务逻辑，但并不彻底。
有时候业务处理还是能够感觉到网络的存在，我觉得这是个不良的设计。
让我耿耿于怀的，是Reactor的单线程特性。或许在某些情况下这是它的优势，但运用不当，就会成劣势。现在的TIM把业务逻辑和网络IO都挤进了Reactor所控制的线程中，只要存在一点点的阻塞，吞吐率将大打折扣。
wildfire敢把网络和业务绑得那么紧，是因为它采用的per-request，per-thread的模型，网络IO引起的阻塞不会影响到其他request处理。我也没有wildfire那么大的胆子采用per-request，per-thread，上下文切换的消耗不说，毕竟线程的数量也是有限制的，我很怀疑到底能承受多少连接数，如果没有记错，Linux没有重编译内核，一个进程内最多是1024个线程，Windows能多些，好像是65535，数据可能不准确，但也说明了线程资源是有限的。同时，WFMOReactor在Windows下每个线程内可同时监视的句柄数（62个），也似乎太少了，这点也让我烦恼。
仔细推敲后，我认为还是把网络和业务完全脱离比较好一点，用至少一个线程专门操作套接口，突破WaitForMultipleObjects的句柄数限制，再用另外一个线程来完成业务。在业务线程上使用管道过滤器模式来一步一步的处理数据。当Reactor线程接收到数据后，放进MessageBlock里面，用Task框架来处理。
这种模型确实解决了原先的诸多毛病，但如果在这个时候改网络模型，对整个项目是个不小的冲击，极有可能导致在计划的时间内不能完成项目。犹豫了一下，为了保证品质，最终还是在SubVersion上创建了新的试验分支。

HuYi 2006-03-27 22:54 发表评论

cyrus_sasl API使用方法

HuYi — Sun, 19 Mar 2006 03:21:00 GMT

/* This is a proposed C API for support of SASL
*
*********************************IMPORTANT*******************************
* send email to chris.newman@innosoft.com and cyrus-bugs@andrew.cmu.edu *
* if you need to add new error codes, callback types, property values,  *
* etc.   It is important to keep the multiple implementations of this   *
* API from diverging.                                                   *
*********************************IMPORTANT*******************************
*
* Basic Type Summary:
*  sasl_conn_t       Context for a SASL connection negotiation
*  sasl_ssf_t        Security layer Strength Factor
*  sasl_callback_t   A typed client/server callback function and context
*  sasl_interact_t   A client interaction descriptor
*  sasl_secret_t     A client password
*  sasl_rand_t       Random data context structure
*  sasl_security_properties_t  An application's required security level
*
* Callbacks:
*  sasl_getopt_t     client/server: Get an option value
*  sasl_logmsg_t     client/server: Log message handler
*  sasl_getsimple_t  client: Get user/language list
*  sasl_getsecret_t  client: Get authentication secret
*  sasl_chalprompt_t client: Display challenge and prompt for response
*
* Server only Callbacks:
*  sasl_authorize_t             user authorization policy callback
*  sasl_server_userdb_checkpass check password and auxprops in userdb
*  sasl_server_userdb_setpass   set password in userdb
*  sasl_server_canon_user       canonicalize username routine
*
* Client/Server Function Summary:
*  sasl_done         Release all SASL global state
*  sasl_dispose      Connection done: Dispose of sasl_conn_t
*  sasl_getprop      Get property (e.g., user name, security layer info)
*  sasl_setprop      Set property (e.g., external ssf)
*  sasl_errdetail    Generate string from last error on connection
*  sasl_errstring    Translate sasl error code to a string
*  sasl_encode       Encode data to send using security layer
*  sasl_decode       Decode data received using security layer
*
* Utility functions:
*  sasl_encode64     Encode data to send using MIME base64 encoding
*  sasl_decode64     Decode data received using MIME base64 encoding
*  sasl_erasebuffer  Erase a buffer
*
* Client Function Summary:
*  sasl_client_init  Load and initialize client plug-ins (call once)
*  sasl_client_new   Initialize client connection context: sasl_conn_t
*  sasl_client_start Select mechanism for connection
*  sasl_client_step  Perform one authentication step
*
* Server Function Summary
*  sasl_server_init  Load and initialize server plug-ins (call once)
*  sasl_server_new   Initialize server connection context: sasl_conn_t
*  sasl_listmech     Create list of available mechanisms
*  sasl_server_start Begin an authentication exchange
*  sasl_server_step  Perform one authentication exchange step
*  sasl_checkpass    Check a plaintext passphrase
*  sasl_checkapop    Check an APOP challenge/response (uses pseudo "APOP"
*                    mechanism similar to CRAM-MD5 mechanism; optional)
*  sasl_user_exists  Check if user exists
*  sasl_setpass      Change a password or add a user entry
*  sasl_auxprop_request  Request auxiliary properties
*  sasl_auxprop_getctx   Get auxiliary property context for connection
*  sasl_auxprop_store    Store a set of auxiliary properties
*
* Basic client model:
*  1. client calls sasl_client_init() at startup to load plug-ins
*  2. when connection formed, call sasl_client_new()
*  3. once list of supported mechanisms received from server, client
*     calls sasl_client_start().  goto 4a
*  4. client calls sasl_client_step()
* [4a. If SASL_INTERACT, fill in prompts and goto 4
*      -- doesn't happen if callbacks provided]
*  4b. If SASL error, goto 7 or 3
*  4c. If SASL_OK, continue or goto 6 if last server response was success
*  5. send message to server, wait for response
*  5a. On data or success with server response, goto 4
*  5b. On failure goto 7 or 3
*  5c. On success with no server response continue
*  6. continue with application protocol until connection closes
*     call sasl_getprop/sasl_encode/sasl_decode() if using security layer
*  7. call sasl_dispose(), may return to step 2
*  8. call sasl_done() when program terminates
*
* Basic Server model:
*  1. call sasl_server_init() at startup to load plug-ins
*  2. On connection, call sasl_server_new()
*  3. call sasl_listmech() and send list to client]
*  4. after client AUTH command, call sasl_server_start(), goto 5a
*  5. call sasl_server_step()
*  5a. If SASL_CONTINUE, output to client, wait response, repeat 5
*  5b. If SASL error, then goto 7
*  5c. If SASL_OK, move on
*  6. continue with application protocol until connection closes
*     call sasl_getprop to get username
*     call sasl_getprop/sasl_encode/sasl_decode() if using security layer
*  7. call sasl_dispose(), may return to step 2
*  8. call sasl_done() when program terminates
*
*************************************************

从sasl.h中截取的。

HuYi 2006-03-19 11:21 发表评论

tim中的SASL

HuYi — Sat, 18 Mar 2006 10:19:00 GMT

2006.03.18
今天弄了一天cyrus-sasl，到下午6点才算跑起来了，我用的版本是2.1.21，在Win2003下编译。

就是红框中的错误折磨了我一整天。
编译这个其实挺麻烦的，要先安装platform SDK，用2000版的nmake。
还要加一些参数。
我懒得加了，直接改了common.mak和win32目录下的config.h文件.
解决上面提到的错误的方法，是config.h中
#define PLUGINDIR "./sasl2"
这个plugin目录的设置，之后需要把生成的saslxxxx.dll文件拷贝到对应目录下。

晚上开始写SaslServer，但愿能顺利。
GoodLuck!

HuYi 2006-03-18 18:19 发表评论

XmlPullParser和SocketReader的思索

HuYi — Mon, 06 Mar 2006 15:38:00 GMT

今天再次Review了代码，但思路却因此而开始混乱。

从名字上解这两个对象：
XmlPullParser当然是以“拉”的方式从流中获取信息。
SocketReader单从字面上理解，功能自然是从Socket上获取字节流。

“单一职责原则”，在几年前就在我脑子里打下了烙印。The Simpler The Easier，既是我做人的原则，也是我做程序的原则。常理上讲，我应该尽力维护这个原则，让上述两个对象都尽可能的简单。在wildfire中，也有SocketReader，然而它的SocketReader却不是那么简单，功能远远超出了字面意义。大部分业务都要靠这个来控制，分配。
受它影响（之前我通读了wildfire的所有源码），在tim中也给SocketReader的子类ClientSocketReader等加上了重担。因为它掌握了太多的信息，应该说大多数信息都暴露在这个地方，Session，Socket，SocketConnection，我实在找不出理由不让它参与进业务。也许，这是OO的一种失败，但我一时也找不到新对象来管理这一系列的相关信息。
XmlPullParser则和SocketReader息息相关，因为Socket中Read出来的东西首先就要经过Parser，才能从字符流形成有用的东西。
在原先的设计中，XmlPullParser被SocketReader所包含，并提供了get方法暴露给外界。在很多事件分配的地方，都要XmlPullParser提供信息，之前，都是通过SocketReader间接获取xpp，高层真的需要直接使用xpp吗？我觉得不然，高层需要的信息完全可以通过SocketReader来提供。
那么该怎么设计两者的关系呢？是包含，还是父子？我倾向于包含，但懒惰促使我选择了父子。目前看起来，父子关系并没有带来什么坏的影响，如果有必要，今后再重构吧。
现在结构似乎更为清晰了，SocketReader的子类（ClientSocketReader。。。）会负责解析流，并根据解析出的内容进行第一层处理，如选择下级处理器或者是直接计算业务，或者是进行转发。。。根据不同的子类，表现不同的业务族（Client，Server，Agent。。。）

HuYi 2006-03-06 23:38 发表评论

“iq” stanza处理

HuYi — Mon, 06 Mar 2006 06:52:00 GMT

按照全局的事件分配机制，iq包被InputHandler所分配。
Iq包有两个小特点：
一是不需要像auth那样持续对话，服务端只收一次包就可以把一个iq业务处理完。
二是Iq包的接收和应答是无序的，靠id对应起来。

那么iq的处理机制，该怎么设计呢？

HuYi 2006-03-06 14:52 发表评论

TIM中的XmlPullParser

HuYi — Mon, 06 Mar 2006 03:08:00 GMT

2006.03.05
今天晚上Parser崩溃了，这个临时性的东西真不好伺候阿。

2006.03.06
重新写了一个“临时”的新PullParser，看起来能应付应付了，不过暂时还是不想把精力放到这个上面，今后再说吧，能测试就行了。不知道什么时候能找到朋友帮帮我啊。

HuYi 2006-03-06 11:08 发表评论

TIM中c2s的事件反应模型

HuYi — Fri, 03 Mar 2006 05:40:00 GMT

摘要: 为了更容易理解后面的内容，先给出登录jabber服务器的交互包。登录的xml片断Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1C: 2... 阅读全文

HuYi 2006-03-03 13:40 发表评论