转载：http://www.cnblogs.com/zc22/archive/2010/05/30/1747300.html
前言
----------------
这阵子，在集成通讯框架， 由于不想自己造轮子，因此参考了现在一些开源的IM框架，结果是。。。。。
让我有点不爽，导致开发的时间不多，但是debug的时间浪费的太多了！
现在让我慢慢小结一下，希望后人不要重走覆辙。
----------------
QQ的相关资料
----------------
qq是从LumaQQ开始的，我个人觉得，应该是认识了腾讯的人，才有可能了解到他们的加密算法，否则外人几乎不可能破解。
之后到了LumaQQ.net，可是05协议之后就停止了，有不少人持续研究，但是没有开源，不过有个超牛逼的家伙（听说还在中学。。） ，叫小虾，持续的保持开源精神。然后也有位c#人士叫dobit帮助了小虾一把，继续推动了lumaQQ.net.
可是非常不幸的是，到了10协议的时候，我发现腾讯采取了新的算法，估计现有qq的开源没多少生命力了（除非又有腾讯的员工放水） 。
所以，目前09协议仍然可以在c#运行，但是按照腾讯的更新率，应该2、3年时间就会淘汰。
架构方面：
LumaQQ.net，我个人觉得代码写的十分的紧耦合 ，后期如果要扩展新的功能会非常困难。不过如果仅仅是协议变化，LumaQQ.net是没有问题的。
Bug方面：
1. 有很多的空指针问题，特别是socket部分，当运行一段时间之后，会出现空指针。
2. 目前发现有部分逻辑问题，导致发送ping命令出错。
稳定性方面：
在修改了bug之后，目前稳定运行12个小时左右是没有问题，继续测试中。
-------------
Msn相关资料
-------------
msn的开源是DotMsn，可惜也是到了06年就停止开发了，后来出来了 MSNPSharp，继承了DotMsn的框架，继续更新到了2010年4月。
DotMsn是我最头疼的框架，写的实在是太乱七八糟。特别是那个conversation的结构，实在让我想吐。在DotMsn里面，要建立会话，首先要创建Conversation对象，然后在通过这个对象SendMessage。
可是最重要的一个callback——SessionEstablished，作者竟然没有“明确的”告诉用户，所以当用户快速发送消息的时候，可能出现链接没有建立的问题。于是在DotMsn时期，出现了各种使用Switchboard之类的轮训判断是否建立的做法。在我看来，这简直就是侮辱了微软的Msn...
到了MSNPSharp，基本上没做任何修改，沿用了DotMsn的结构，然后基于了 MSNP18 协议实现了。
架构方面：
DotMsn的架构实在非常不明确，特别是这个所谓的Conversation的思想，可以说是个超级败笔。即使作者想面向对象，请使用异步，而不是同步返回Conversation. 其他的就凑合，handler用switch去选择之类的，算是个得过且过的思路，扩展性也几乎很低。
再提一个很糟糕的架构设计，就是一个相同的对象，竟然可以从不同的其他对象中返回，比如 NSMessageHandler 等。导致我不知道什么时候应该用哪个。。
Bug方面：
如果按照DotMsn所期望的去使用，是没有bug。但是我到现在，还没有搞清楚DotMsn期望我怎么去“正确使用”。目前，使用MSNPSharp能够正确发送信息、接受信息，但是一段时间，会发现信息无法发送的问题，也没有提示出错。正在研究“我到底哪里没有符合DotMsn的期望”中。
稳定性方面：
比较稳定，如果能正常登录，就保持登录。但是可能会不能正产登录。
--------------------------
Gtalk相关资料
--------------------------
Gtalk号称使用了 XMPP协议，然后又有个号称是很牛叉的agsXMPP的实现了这个协议，顺便“照顾”了一下Gtalk. 于是c#就能够Gtalk了。
当然，agsXMPP为了兑现他的“牛叉” ，整个框架被分的非常的“细腻”，最终导致了一个结果：小类满天飞。一个几乎是空内容的class都会被new出来。我也没功夫去研究这一堆类是干什么的。
当然，“牛叉” 不是白来的，在agsXMPP几乎没怎么变动，过了几年到现在，仍然能够正确通讯gtalk，也算是比较放心（也怪google没有花时间升级gtalk）。
架构方面：
非常的细腻，以致我没工夫去分析到底是怎么写的。不过从项目的层次结构上看，是很清晰的。只要砸时间下去，能够搞清楚架构。
Bug方面：
到目前未知，还没有发现bug。
稳定性方面：
偶尔断线，不过我能够直接获取socket抛出的异常，所以也能正确的重新链接。不过gtalk让我最恶心的就是无法连续发送信息，大约10条信息之后，就会出现ServiceUnavailable问题。我只好忍痛割爱了。。。如果没这个问题，我早就放心的用了。
--------------------------
Fetion相关资料
--------------------------
Fetion的资料就是官方的资料，直接反编译就能够获得。不过可笑的是，即使反编译得到了原汁原味的代码，大部分人还是不知道写的是什么。
Fetion架构上参考了DotMsn，因此我已经有点不爽了。
不过由于Fetion的协议设计上和Msn不同，所以不存在先建立Conversation，再发送信息，因此这个“没有意义”的Conversation基本上可以拿掉了。
Fetion本质是可以直接从connection发送指定接受者的信息的。而Msn的协议设计是一种Chat模式，就是多对多的设计，因此要建立一个所谓的Conversation(具体我没有研究，不知是否可以直接点对点发送) 。
由于Fetion的通讯协议（sip??） 还是非常的不错，所以后来有个牛人HaozesFx大大的拆解了源代码，简化了一些结构。所以如果使用HaozesFx的用户，还是能够满足要求的。至于网络有个家伙仅仅反编译了fetion再打包就说是 FetionSDK的，建议大家不要用，这个SDK基本上就一个垃圾，用上去会浪费很多时间去debug 的。
架构方面：
混乱。无法解释。
Bug方面：
目前没有发现什么bug。
稳定性方面：
断线问题仍然存在，不过能直接获取socket的exception，能够解决。
---------------------
最后小结
---------------------
如果我排序，那么从差到好的顺序是：
(最差) Fetion -> DotMsn -> MSNPSharp -> LumaQQ.NET -> HaozesFx -> agsXMPP (最好)
如果有人想用这些DLL，那么请选择MSNPSharp, LumaQQ.net, HaozesFx, agsXMPP，其他的，就让他们去吧。
最近有不少对fetion不利的文章，客观说，fetion的通讯协议是非常的漂亮的，因为sip本来就设计的不错。只是写fetion客户端欠缺了。
不过我还是觉得，自己重写算了。不知道为什么现在的IM框架都这么复杂，通讯协议的处理层本身就应该和业务逻辑分离成2个项目。比如针对SIP实现一个处理层，成为一个XXXManager，之后再在上面实现各种对话等操作。
等我把MSNPSharp解决了，再思考一下这个问题。