IM

下面三个是针对qq分析的 1、 http://www.cnblogs.com/stable/archive/2010/07/17/1779467.html IM服务器架构实现 2、 http://smallprogrammer.blog.163.com/blog/static/13165992820095259577713/ IM服务器结构设计思路 3、 http://mobile.51cto.com/hot-439693.htm 下面的是针对skype分析的 4、 http://news.cnblogs.com/n/72565/ 5、 http://wenku.baidu.com/link?url=nRlwCb7bA1z4xTh6FbIUY1XmV_BjO-VKVd2PxC--62KC2K8sPtSqtAX5YzfqROmWPVLSKTaGFPgbARFpX8bSE-_P5oVzqGdVY68Ug-YyeWy 6、webrtc http://www.infoq.com/cn/news/2011/06/google-webrtc 来源： oschina 链接： https://my.oschina.net/u/1251232/blog/297491

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 序言 我们在业务处理过程中，经常要处理各种信息，比如：站内信息、邮件信息、还可能有短信、彩信，甚至可能与各种IM软件进行对立的信息系统。 Tiny框架也需要面对这个问题，不一样的是我觉得这几种类型的信息处理模式都是一样的，因此试图采用统一的模式进行处理。 在开始之前，我们先梳理一下需求： 可以支持各种信息系统如：短信，彩信，邮件，IM，站内信息的接收与发送 在接收或发送消息的时候可以进行各种逻辑处理，比如：收到某种类型的邮件怎么处理，收到某种内容的短信怎么处理。 邮件收到的时候，可以不删除，可以删除，也可以改成已读等各种状态 发送邮件的时候，可以附加各种附件，比如：来自文件的，来自内存的等等 概念抽象 因此，我们就抽象了下面的几个概念： MessageAccount：接收信息或发送信息时，需要帐户，因此抽象一个信息帐户概念。 MessageReceiver：信息接收者 MessageSender：信息发送者 Message：要发送的信息，对应于邮件，短信，彩信之类 MessageReceiveService：用于提供信息发送服务 MessageSendService：用于提供信息接收服务 MessageException：用于在出现问题的时候，抛出异常 MessageSendProcessor

1、问题背景 因为我用Linux系统（Ubuntu），所以登录QQ一直我的难题。WebQQ确实不错，但我还是想要pidgin与 empathy那样的风格。把多个im整合在一起。 上次我介绍了（http://my.oschina.net/noahxiao/blog/88687）empathy这次来说说pidgin，因为单从功能的角度考虑pidgin还是一个不错的选择。 2、解决步骤 pidgin-lwqq是基于lwqq开发的pidgin插件。lwqq又是基于webqq协议开发，本人比较赞同作者的思路。 对pidgin下支持： 支持发送接受文本消息 支持发送接受图片 支持群聊天 支持发送接受表情(在设置中使用webqq表情主题) 支持头像 支持设置好友备注 支持更改好友分组 支持确认添加好友请求 支持群的临时会话 支持访问QQ空间 支持更改在线状态 支持多账户登录 支持发送接受离线文件 支持文本样式 支持群消息屏蔽 支持接受文件传输 对empathy下支持 (telepathy-haze，受到这个框架的限制) 支持发送接受文本消息 支持头像 a、安装 pidgin-lwqq（ppa） sudo add-apt-repository ppa:lainme/pidgin-lwqq sudo apt-get update sudo apt-get install pidgin-lwqq b

http://www.csdn.net/article/2012-09-10/2809790-zoosk-the-engineering-behind-real-time 摘要： Zoosk是一个具有5000万会员的浪漫的社交约会网站，为了更好的让用户体验实时通信，让他们获得更有价值的消息，公司对实时通信背后的技术进行了深入开发。本文就是其开发工程副总裁Peter Offringa所写，主要讲述了Zoosk背后的实时通信技术。 导语： 本文由Zoosk（一个具有5000万会员的浪漫的社交约会网站）工程副总裁Peter Offringa所写，讲述了Zoosk的实时通信技术。 当我们的会员从Zoosk获得的最有价值的消息时，他们可以实时进行交互。毕竟，每个用户其连接的另一端都可能在未来产生关系。这种情况的兴奋和丰富才能充分实现实时。该套件的Zoosk服务促进这些交互一般被描述为实时通信(RTC)。这些通信交付使用XMPP协议，其他流行的即时通信产品也使用该协议。Zoosk的会员在三个不同的相互作用中体验实时通信： 存在 。当一个成员正在积极地连接到 Zoosk RTC的基础设施时，其公共的状态将显示为“可用”。如果他们一段时间内均处于空闲状态，它们的状态过渡到“离开”。他们关闭或断开连接的客户端应用程序时，他们的存在将自动更改为“离线”。会员还可以选择显示“隐身”的状态呈现给其他用户

Oschat IM Oschat IM是一个开源的即时通信项目，包括基于websocket的服务器端和基于 node-webkit 的客户端。为什么我要做这个项目，一是先有的开源即时通讯项目很少，多数企业是选择Openfire+Spark进行二次开发，或者采购腾讯通这样的产品进行业务的集成。二是这样的开源项目的客户端基本是采用Swing或者c++编写，相对于node-webkit采用html5+js进行开发的，重写修改起来对开发人员的要求要高得多，精通web开发的人员数量也多的多。用html5写出来的界面也更加美观方便。这就是我做这个的初衷。 一、Oschat Server Oschat IM的服务器端架构主要基于Akka+Servlet。客户端与服务器端的通信数据格式用的是json，这里并没有打算去实现XMPP规范，因为我们不需要与其他IM进行通信。我也懒得去研究XMPP了。Servlet作为与客户端通信的接口，当websocket接受到消息便交给Akka系统处理，Akka会找到接受消息人的MessageInbound实例，然后把消息发送给接受人的客户端。 1、为什么选择Akka Akka 是一个用 Scala 编写的库，用于简化编写容错的、高可伸缩性的 Java 和 Scala 的 Actor 模型应用。它已经成功运用在电信行业。系统几乎不会宕机（高可用性 99.9999999

openfire更新也算很快了，已经到4.0.2，目前生产版本是3.9.3，二次开发后，优化很大，且运行稳定。但技术习惯一直保持版本跟踪，今天试安装了一下，遇到一些问题，记录。 1，建库表： CREATE DATABASE of4d DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; --# 导入 openfire_mysql.sql #-- -- CREATE USER 'of4'@'%' IDENTIFIED BY '123456'; -- GRANT ALL ON of4d.* TO 'of4'@'%'; #openfire.xml# jdbc:mysql://mysql-server:3306/db?rewriteBatchedStatements=true&useUnicode=true&characterEncoding=utf8 2，debug运行的时候，无法登陆： 此乃openfire的一个bug，修改： LockOutManager->getUserLockOut()，lockOutCache.put(username, flag);此时flag有可能为null，是无法存储到cache的，需要添加判断，修改后，以admin用户进入系统。, 3，创建用户test1,test2,test3 4，用spark登陆

上篇bolg( agsXMPP + Openfire 即时通讯开发（一） 【agsXMPP 连接 Openfire】 )中agsXMPP的MiniClient已经可以相互之间进行通讯了，本篇介绍如何进行文件传输。 首先我们需要了解XMPP文件传输的整个对话过程： 这篇文章 写的比较详细 或者你可以查看XMPP源文档 XEP-0052 (PDF) 通过阅读以上文档我们已经了解XMPP传输文件前的对话过程，接下来按照上面的步骤完成消息对话。 当然前提是需要你看懂MiniClient的XML收发代码，其实在文件传输过程中，70%的时间我都花费在阅读agsXMPP 的代码上了，20%调试，10%才是我对代码的改动。 注意： 1、获取代理服务器后，与代理服务器通信的Jid需要这样获得 Jid jid = new Jid("proxy.127.0.0.1") 当你获取代理服务器资源和激活数据流的过程中需要用这个jid。 2、在同一次文件传输过程中xml消息的SID，都应该保持一致，同时Socket5连接的SID也应该为同一个SID。 3、无论文件接收端链接代理还是文件发送端链接代理，Socket5链接的Initiator属性设置为文件发送端的Jid，Target属性设置为文件接收端的Jid。 来源： oschina 链接： https://my.oschina.net/u/270180

项目中有这么一个需求： 1. 间隔一分钟，查询XMPP服务器，获取在某个聊天室中的成员信息 2. 获取查询结果，做相应处理 查询XMPP协议，发现XEP-0045文档有做相关的协议说明： http://xmpp.org/extensions/xep-0045.html#disco-roomitems ，用到的是多用户聊天室（MUC）的discovery操作，对应的Namespace Uri为： http://jabber.org/protocol/disco#items 查询消息定义： <iq from='you jid' id='message id' to='roomJid' type='get'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq> 正常的查询结果消息格式定义： <iq from='roomJid' id='message id' to='you jid' type='result'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='roomJid/member1NickName'/> <item jid='roomJid/member2NickName'/> </query> </iq>

转自: http://www.biaodianfu.com/huanxin.html 即时通讯(IM)功能是APP的重要功能之一，而开发好移动IM却绝非易事。通常来说，IM技术选型至少要解决以下问题： 协议选型 IM服务器选型 对协议和服务器做相应修改，通常来说直接拿个标准协议和开源服务器是一定不能用到生产环境的 保证消息到达率，绝不丢消息 以上4点搞定后基本就有了一个可用的IM平台上。想更上一层楼，可以对电量和流量等做进一步优化，或者研究怎样支持百万级以上的用户。 协议选型 常用做IM的协议： IM 服务器选型 常见的开源IM服务器 标准协议及IM服务器的改进 XMPP协议的问题及改进 登陆握手部分的改进：XMPPQuickStart （XEP0305） 心跳改进：Xmpp Ping/Pong (XEP0199)40+字节 －> 单向 whitespace ping 4字节 文件传输：Xmpp协议的文件传输是点对点，需要改成用http上传的server，语音视频压缩后上传 Presence：对移动互联网场景，不转发是否在线（永远在线） Muc聊天室：Muc是群聊天协议，要改进成移动社交app中的群组，发送消息时发送给群里的所有用户，而不是只发“在线”用户，disable presence Openfire源码级别改进 发送消息回执：java 里维护一个发送消息的队列

缘于公司使用的通讯通RTX，按用户数购买license，于是乎我就想到网上找找有没有开源的。 百度之，推荐的有IPMSG，飞秋，和openfire+spark。 1、IPMSG，功能简单易用，就是界面粗糙了点。 2、飞秋，在IPMSG基础上加上了类似QQ的界面风格，而且文件传输什么的更好用了。 3、openfire+spark，以上2个软件的缺点是无法发送离线消息，而且历史聊天记录很容易丢失，组织架构随意且混乱。那么这个组合就比较符合要求，虽然和RTX相比，对中文支持不美观，而且不符合长期使用QQ的用户的习惯。 对比RTX，openfire+spark特点如下： 1、没有群，只有会议室，会议室是人来人往，不像群一样固定，但是可以限定那些人可以进入会议室。会议室可以在服务器端设置为固定的，或者在客户端创建临时的。 2、可以像RTX一样在服务器端设置统一的组织架构，而且可以简单实现多级架构，在客户端为spark的时候，方法为：在组的显示名中以 :: （空格，冒号，冒号，空格）分隔主组和子组，而且主组不能有成员，且在spark中会显示一行“此组没有用户在线”的提示，很不友好。 3、可以从客户端申请新用户。 4、会话框不符合国人习惯。 来源： oschina 链接： https://my.oschina.net/u/105376/blog/37418