MUC
房间属性设置
以上属性存储在MUCPersistenceManager
private staticConcurrentHashMap<String,MUCServiceProperties> propertyMaps =newConcurrentHashMap<String,MUCServiceProperties>();
创建房间
客户端创建房间案例
第一：客户端发出查询请求
服务器将数据包发送到托管在该服务器组件来处理。
routed = routeToComponent(jid,packet, routed);
服务器需要在内存中判断房间是否存在，其次呢，返回外部组件的配置。为确切请求子域的查询将会作出修改。如果没有被发现和使用通配符请求，然后再查询将被提出，在使用通配符这个时候。
然后检查组件是否被托管在此JVM
获取MUC组件的信息
该MUC服务将接收的域MUC的域相匹配的所有数据包服务。这意味着，例如，disco 请求应该由服务本身作出回应，而不是依赖在服务器上处理请求。
根据命名空间找到相应处理——>IQDiscoInfoHandler。
寻找与所请求的实体相关的DiscoInfoProvider。
我们认为该数据包为单位的接收者的JID的主机。这是DiscoInfoProvider责任提供有关的JID的姓名信息一起用任何可能的请求节点。所查询的房间节点不存在，按照正常的流程服务器返回错误信息
客户端第二轮发送：
服务器处理：
1.将用户发送的定向存在的实体
(通知方式发送到该处理程序，当用户发送了一个指向存在的实体。如果存在的发件人是本地的（这个服务器）和目标实体不属于用户的花名册，然后发送更新派驻执导的用户注册表。)
2.广播到所有连接的资源（获得由XMPPAddress聊天的用户。仅返回已连接到该JVM的用户。）
服务器返回消息：
确认配置之前已锁住该房间，禁止进入。
配置钱锁定房间，一面别的用创建一样的，或者申请加入这个房间
客户端发送IQ：
查询房间拥有者。
服务器返回1：
确认配置之前已锁住该房间，禁止进入。
服务器返回2：
======================================================================
总的对话
客户端发送C2S - RECV (32671720):
服务器返回
以上循环两次对话，这可能由于debug超时原因，消息重复发送。
客户端发送
出席消息。
服务器处理：
1.当用户发送一个 directed presence的时候将发送给directedPresenceSent()来处理。如果存在的发件人是本地的（这个服务器）和目标实体不属于用户的花名册，然后发送更新派驻执导的用户注册表。
跟踪所有指示派驻人员名册，如果服务被禁用
这里有两块内存记录消息：
private Cache<String,Collection<DirectedPresence>>directedPresencesCache;
跟踪发送指向派驻到其他实体。
在这个Cache上我们跟踪每一个 directed presence存在，无论发送者是否托管在这个JVM或其他群集节点。另一个
private Map<String,Collection<DirectedPresence>>localDirectedPresences;
发送相同directedPresencesCache但只有不断派驻指导
用户连接到该JVM。在方法directedPresenceSent()中主要对两个变量开始操作，这里有一个开锁和解锁的过程。
updateHandler.directedPresenceSent(packet, jid, recipientJID.toString());
2.路由消息包
被发送到XMPP域的组件路由数据包（这是XMPP域的子域）
首先检查组件是否被托管在此JVM
存在，交由component.processPacket(packet);出数据包
该MUC服务将接收的域MUC服务的域相匹配的所有数据包。
这意味着，例如，disco请求应该由服务本身作出回应，而不是依赖在服务器上处理请求。在getChatRoom()方法中会从数据库中加载了房间的配置（如果房间是持久性的，但被添加到数据库服务器启动或房间可能是旧的房间，这是不存在于记忆体后）
这里OF服务器检查到房间需要重新创建的情况下，它没有预先创建（或已被删除不知何故，预计委托存在）。
因为房间不存在，所以接下来就该检测拥有者的创建权限了。依次添加room到内存中，以免其他创建者冲突。
开始创建房间事件——>通知其他集群节点，一个新的空间可用.
检查客户端创建密码或客户端对MUC的支持
(注：获取房间组件的基本信息
Long serviceID = XMPPServer.getInstance().getMultiUserChatManager().
getMultiUserChatServiceID(room.getMUCService().getServiceName());)
服务器返回1：
给自己发送出席
服务器返回2：
确认配置之前已锁住该房间，禁止进入。
客户端发送：
根据namespace服务器将有IQOwnerHandler来处理
refreshConfigurationFormValues()房间配置信息
服务器返回：
房间配置 已创建房间“room2”。要接受缺省配置，请单击“确定”按钮。 或填写以下表单以完成设置： http://jabber.org/protocol/muc#roomconfig room2 room2 1 30 moderator participant visitor 1 1 1 1 注意：缺省情况下，只有管理员才可以在仅用于邀请的房间中发送邀请。 1 0 如果需要密码才能进入房间，则您必须在下面指定密码。 anyone 1 1 1 允许用户注册房间 1 您可以指定该房间的管理员。请在每行提供一个 JID。 您可以指定该房间的其他拥有者。请在每行提供一个 JID。 test2@8ntmorv1ep4wgcy
客户端发送1
http://jabber.org/protocol/muc#roomconfig room2 测试2 test2@8ntmorv1ep4wgcy
在这一步操作，是客户端来设置房间的一些配置信息，并且保存到DB(在类LoaclMUCRomm.saveToDB()方法中)
然后保存用户(普通用户，管理员).
服务端返回1
该房间现在已解锁。
服务端返回2
客户端发送
处理类：IQDiscoInfoHandler
服务端返回
http://jabber.org/protocol/muc#roominfo 测试2 1 20131202T02:22:08
加入房间
客户端加入房间，首先获取房间信息
服务端通过查找服务器组件获取房间信息并返回如下报文
http://jabber.org/protocol/muc#roominfo 测试房间2 0 20131202T07:08:32
客户端再次发送状态
服务端返回：
该房间不是匿名的。
邀请用户
请求用户发送消息内容
请把我加入会议中。
组件将消息发送给客户端test1，如图：
Test1接收邀请
发送消息：
服务端将发送如下消息
OK,关于会议室这块就到次结束。这里读起来很难理解很正常。基于xmpp协议的通讯消息太繁琐了。但是只要读者细心debug调试，还是不难的。
我在上面中的jid，如：jid="test2@8ntmorv1ep4wgcy/Spark 2.6.3#android，这里面有个#号。而实际上在openfire正常的通讯是没的
这是本人调试测试多加了个jid属性。关于jid部分，本人会单独拿出来写博文的。欢迎阅读，不对之处请联系本人指正。本人邮箱：
624308915@qq.com