xmpp muc 群聊协议 1

翻译来自 :http://wiki.jabbercn.org/index.php?title=XEP-0045&variant=zh-cn#.E6.9C.AF.E8.AF.AD

通用术语

Affiliation(岗位) -- 一个长期存在的和房间之间的联系或连接; 可能的岗位有 "owner"(所有者),
"admin"(管理者), "member"(成员), 以及 "outcast"(被排斥者) (当然也可能没有岗位); 岗位从角色来看是唯一的.
一个岗位跨越了用户对一个房间的访问期间.

Ban(禁止) -- 从一个房间移除一个用户以使这个用户不能够再进入这个房间 (直到这个禁令被废除为止). 一个被禁止的用户的岗位为
"outcast"(被排斥者).

Bare JID(纯JID) -- 一个用户的标识符 <[email protected]>, 不同于任何已有会话或资源的上下文,
与之相对的是全JID和房间JID.

Full JID(全JID) -- 一个在线用户的标识符 <[email protected]/resource> ,
不同于一个房间的上下文; 与之相对的是纯JID和房间JID.

GC -- 最小的 "groupchat 1.0" 协议[7], Jabber社区于1999年开发; MUC 向后兼容GC.

History(历史) -- 有限数量的消息节, 由当前讨论的上下文提供发送给一个新的房客.

Invitation(邀请) -- 从一个用户发出的特殊消息给另一个用户, 邀请对方加入房间.

IRC -- Internet Relay Chat.

Kick(踢人) -- 临时从一个房间移除一个与会者或游客; 这个用户任何时候都可以再次进入这个房间. 一个被踢的用户的角色是"none".

Logging(记录) -- 存储发生在一个房间的讨论内容用于公开发布到房间背景之外的地方.

Member(成员) -- 一个用户在一个仅限会员的房间内处于"white list"(白名单)内,或已经注册到一个公开的房间.
一个成员的岗位是"member".

Moderator(主持人) -- 一个房间角色,通常和房间的管理有关但是这个角色可以被赋予非管理员; 可以踢人, 可以授予和撤销发言权, 等等.
一个主持人的角色是"moderator".

MUC -- 本文所定义的基于文本会议的多用户聊天协议.

Occupant(房客) -- 一个房间里的任何Jabber用户 (这是一个 "抽象类"
并且不对应任何特定的角色).

Outcast(被排斥者) -- 一个被某个房间禁止的用户. 一个被排斥者的岗位是 "outcast".

Participant(与会者) -- 一个没有管理权限的房客; 在一个被主持的房间里, 参与者更多地被定义为有发言权的
(与之相反的是游客). 一个与会者的角色是"participant".

Private Message(私有消息) -- 从一个房客直接发给另一个房间JID的消息(不是房间本身广播给所有房客的消息).

Role(角色) -- 在一个房间里的一个临时的地位或者权限级别, 对于这个房间中的用户的长期岗位来说是唯一的; 可能的角色有
"moderator"(主持人), "participant"(与会者), 和 "visitor"(游客) (也可能没有预定义的角色).
一个角色仅仅存在于一个房客访问一个房间的期间.

Room(房间) -- 一个虚拟的地方, Jabber用户象征性地加入它, 来和其他用户一起参与一个实时的基于文本的会议.

Room Administrator(房间管理员) -- 一个由房间所有者授权的用户, 可以执行管理功能, 如禁止用户等等; 无论如何,
不允许改变定义的房间特性. 一个管理员的岗位是"admin" .

Room ID(房间ID) -- 一个房间JID的节点标识符部分, 它可以是不透明的因而对人类用户没有什么含义(见
语法的商业规则Business Rules for syntax); 与之相对的是房间名.

Room JID(房间JID) -- 在一个房间上下文中的一个房客,以 <[email protected]/nick>
来标识; 与之相对的是纯JID和全JID.

Room Name(房间名) -- 一个用户友好的, 自然语言的房间名字, 由房间所有者配置并在服务查询中展示; 与之相对的是房间ID.

Room Nickname(房间昵称) -- 房间JID的资源标识符部分(见语法的商业规则); 这是一个房客在这个房间中所呈现的"友好的名字".

Room Owner(房间所有者) --
建立某个房间的Jabber用户或一个被房间创建者或所有者指派拥有所有者权限(如果允许的话)的Jabber用户; 它被允许改变定义好的房间特性,
也可以执行全部的管理功能. 一个所有者的岗位为"owner".

Room Roster(房间名册) -- 一个房间中的所有房客在一个Jabber客户端的展现.

Server(服务器) -- 一个Jabber服务器,可以关联或不关联一个基于文本的会议服务.

Service(服务) -- 一个主机, 提供基于文本的会议的能力; 通常但不必须是一个Jabber服务器的子域(例如,
conference.jabber.org).

Subject(主题) -- 一个房间的临时讨论标题.

Visit(访问) -- 一个房间的一个用户的"session"(会话), 当用户进入这个房间时开始(也就是说, 成为一个房客) ,
结束于用户离开房间之时.

Visitor(游客) -- 在一个被主持的房间里的一个没有发言权的房客(相反则是一个与会者). 一个游客的角色是"visitor".

Voice(发言权) -- 在一个被主持的房间里, 发送消息给全部房客的权限.

房间类型

Fully-Anonymous Room(全匿名房间) -- 一个房间的房客的全JID或纯JID不能被任何人查询到, 包括房间管理员和房间所有者;
这类房间是不推荐的(NOT RECOMMENDED)或不被MUC显式支持, 但是如果一个服务提供适当的配置选项来使用这个协议,这种情况也是有可能的;
相对的则是非匿名房间和半匿名房间.

Hidden Room(隐藏房间) -- 一个无法被任何用户以普通方法如搜索和服务查询来发现的房间; 反义词: 公开(public)房间.

Members-Only Room(仅限会员的房间) -- 如果一个用户不在成员列表中则无法加入的一个房间; 反义词: 开放(open)房间.

Moderated Room(被主持的房间) -- 只有有"发言权"的用户才可以发送消息给所有房客的房间; 反义词:
非主持的(Unmoderated)房间.

Non-Anonymous Room(非匿名房间) -- 一个房客的全JID会暴露给所有其他房客的房间, 尽管房客可以选择任何期望的房间昵称;
相对的是半匿名房间和全匿名房间.

Open Room(开放房间) -- 任何人可以加入而不需要在成员列表中的房间; 反义词: 仅限会员的房间.

Password-Protected Room(密码保护房间) -- 一个用户必须提供正确密码才能加入的房间; 反义词: 非保密房间.

Persistent Room(持久房间) -- 如果最后一个房客退出也不会被销毁的房间; 反义词: 临时房间.

Public Room(公开房间) -- 用户可以通过普通方法如搜索和服务查询来发现的房间; 反义词: 隐藏房间.

Semi-Anonymous Room(半匿名房间) -- 一个房客的全JID只能被房间管理员发现的房间; 相对的是全匿名房间和非匿名房间.

Temporary Room(临时房间) -- 如果最后一个房客退出就会被销毁的房间; 反义词: 持久房间.

Unmoderated Room(非主持的房间) -- 任何房客都被允许发送消息给所有房客的房间; 反义词: 被主持的房间.

Unsecured Room(非保密房间) -- 任何人不需要提供密码就可以进入的房间; 反义词: 密码保护房间.

时间: 2024-12-30 22:27:33

xmpp muc 群聊协议 1的相关文章

xmpp muc 群聊协议 3

6. Entity Use Cases A MUC implementation MUST support Service Discovery [7]. 服务端必须实现 service discover 6.1 Discovering Component Support for MUC 发现服务器是否支持muc A Jabber entity may wish to discover if a service implements the Multi-User Chat protocol; in

xmpp muc 群聊协议 4

7. Occupant Use Cases The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, par

群聊协议

互动部分协议 流程描述 建立群: 1.客户端去发请求->服务器(我们的协议810) 2.服务器端用管理员xmpp账号建群,并在服务器端记录此账号为群主 3.服务器用管理员xmpp账号发xmpp消息回来,告知群建立成功. 退出群: 1.客户端发请求->服务器(我们的协议812) 2.服务器端从数据库删掉该用户在群里的关系 3.客户端本地发送消息给xmpp服务器,并从本地删除数据.(即使没有删除成功,下次登录群列表也没有该群了) 邀请用户进入: 1.群管理人员使用客户端发请求->服务器(我们

Strophe.js连接XMPP服务器Openfire、Tigase实现Web私聊、群聊(MUC)

XMPP(Extensible Messaging and Presence Protocol)是一种网络即时通讯协议,它基于XML,具有很强的扩展性,被广泛使用在即时通讯软件.网络游戏聊天.Web聊天及Web消息推送.移动设备的消息推送等场景,例如Google的GTalk.<英雄联盟LOL>游戏聊天模块. 由于在Web浏览器上的JavaScript不能直接处理TCP协议,所以XMPP服务器通常会提供BOSH(Bidirectional-streams Over Synchronous HTT

如何解决群聊(MUC)聊天室重复存储、接收自己发送的消息的问题

CHENYILONG Blog 如何#解决方案#群聊(MUC)聊天室重复存储.接收自己发送的消息 编号 项目 描述 1 问题描述 单聊没问题,群聊会出现自动回复的问题 数据库中存储的数据出现的问题 界面上出现的问题:类似自动回复.回音壁一样一模一样地回答.  2 问题产生的原因 3 群聊基本的原理示意图 聊天内容的显示是经由从数据库进行的读取排序, 4 #解决方案# 拦截阻挡红色区域的执行  5 失败的尝试:尝试但是没有效果的方法 // AppDelegate.m中#pragma 接收消息代理监

Java--&gt;实现群聊功能(C/S模式--TCP协议)

--> Java 对TCP协议的支持: --> java.net包中定义了两个类ServerSocket 和Socket ,分别用来实现双向连接的server 端和client 端. --> Client 类定义客户端 package com.dragon.java.tcpchat; import java.io.IOException; import java.net.Socket; import java.net.UnknownHostException; /** * 客户端 * *

XMPP仅借助openfire实现群聊的流程图

其实这种搭建临时聊天室的策略有种"中病毒"的意思,就好比我QQ给你发了一个exe然后你中毒了一样.我们给需要添加进聊天室的小伙伴们统一发送一条消息,同时为消息添加一个结点(相当于exe病毒),上面绑定者我们手动输入的聊天室的名字以及随之而产生的RoomJid,对方用户只要接收到就会被添加进聊天组. 其中的原因在于我们可以很便捷无误地向其他用户发送离线消息,但是离线邀请却不一定能准确送达,必须是用户在线情况下才能收到. XMPP仅借助openfire实现群聊的流程图,布布扣,bubuko

使用java做一个能赚钱的微信群聊机器人(2020年基于PC端协议最新可用版)

前言 微信群机器人,主要用来管理群聊,提供类似天气查询.点歌.机器人聊天等用途. 由于微信将web端的协议封杀后,很多基于http协议的群聊机器人都失效了,所以这里使用基于PC端协议的插件来实现. 声明以下过程只用于交流学习,并不用于任何商业用途,这里记录一下整体的开发流程. 效果展示 接入过程 准备材料 下文中的服务器可以只需要一台,或者使用你本地电脑,我介绍一下我的环境. 可爱猫微信机器人插件V4.4.0. 一台windows服务器. 一台linux服务器. nginx安装(在window服

群聊

XMPP在其XEP-0045扩展中定义了一个用于多用户文本会议(群聊)的协议,类似于聊天室.QQ群等.由于它作为一个标准协议在定义模型上力求完备,涵盖了现实中的绝大部分IM产品模型,而现实中的IM产品基本都只实现了XMPP定义的模型中的一个子集.XMPP定义的一些基本概念:房间:房间的JID标识 <[email protected]> (例如, <[email protected]>), 这里 "room" 是房间的名称而 "service"