专业IM即时通讯软件开发,值得信赖!

曾经有几个开源IM框架(Msn/QQ/Fetion/Gtalk…)

即时通讯软件开发 云聊IM 2145℃

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,之后再在上面实现各种对话等操作。

版权声明:部分文章、图片等内容为用户发布或互联网整理而来,仅供学习参考。如有侵犯您的版权,请联系我们,将立刻删除。
喜欢 (2)
仿微信聊天软件开发
点击这里给我发消息