1

ChatIssues and Ideas for Service Design

Refs: RFC 1459 (IRC)

2

Service Design Issues

• 假设我们要设计一个聊天系统• 我们来看一下在设计过程中需要解决的一些问题• 同时我们也会看到一些可能的系统架构

3

Multi-user Chat Systems功能上的问题（ Functional Issues）

–消息类型Message types.–消息的目的地Message destinations (one vs. many

groups)–可扩展性 Scalability (how many users can be

supported)–可靠性Reliability?–安全性 Security

• 鉴权 authentication• 授权 authorization• 隐私 privacy

4

消息类型Message Types

• 一些可选项 Some options:–只是文本 text only–声音 audio–图像 images–任何东西，象邮件附件一样

anything (MIME)?

5

消息的目的地Message Destinations

• 多用户聊天时，各条消息都发送给一个组 /群。–可以也发给单独的个人吗？–我们是否应该支持不只一个组 /群呢？

• 组是动态的还是静态的？• 如果一个组内没有人会怎样？• 组之间是否通信？• 组可以合并或者分裂吗？

6

可扩展性• 我们想要支持多大的一个组（允许一个组内有多少用户）？• 支持多少个组？• 什么类型的服务架构可以提供有效的消息传递？• 什么类型的服务架构允许系统支持许多的用户 /组？

7

可靠性• 用户需要知道所有其它人都收到了消息吗？• 如果一条消息丢失了会怎样？

–重发？应用层（聊天系统）还是用户自己来做？• 用户退出会怎样？

–其它人需要知道吗？

8

安全性• 鉴权：我们需要知道各用户是谁吗？• 授权：一些用户是否需要有更多的特权？• 隐私：

–消息需要保密吗？–我们需要确保消息不会被伪造吗？

9

Peer-to-Peer Service Architecture

Client

Client

Client

Client

Client

Client

ClientClient

10

Peer-to-Peer Service Architecture (cont.)

各客户端与其它许多客户端直接对话• 谁最先运行呢？这种聊天服务有明确的地址（供客户端来查找）吗？• 我们可以记录多少个对端（ peer ） /客户端• 如果两个客户端在同一台主机上，我们需要向该主机发送两遍同一条消息吗？

11

Client/Server

Client

Client

Client

ClientClient

Client

Client

Client

Server

12

Client/Server

• 服务器地址客户端都知道• 客户端比较简单——不需要知道所有其它的客户端• 客户端的数量有限制吗？• 集中式的安全机制• 服务器会过载（ overloaded）吗？

13

Hybrid Possibility

Client

Client

Client

ClientClient

Client

Client

Client

Server

CONTROL

MESSAGES

14

混合方式 Hybrid

• 客户端连接到服务器、并收集控制信息：–其它客户端的列表–其它聊天组 /群的列表

• 消息是直接发送的（不通过服务器）–可以使用无连接协议 (UDP).

15

Internet Relay Chat （ RFC 1459 ）• IRC 是一个广泛使用的多用户聊天系

统 . –支持许多聊天组（频道）–大量的管理控制–分布式的服务架构– Still in use today, although WWW based

chat is now more common.

16

Client

IRC Architecture

Client

Client

Client

ClientClient

Client

Client

Server Client

Client

Client

ClientClient

Client

Client

ServerServer

Server ServerClient

ClientClient

17

Server Topology

• 服务器之间以生成树的方式相连（一个连通图的生成树是一个极小连通子图，它含有图中全部顶点，但只有足以构成一棵树的 n-1条边）– 任意 2个服务器之间只有一条路径– 服务器可以动态加入（比如选择它所连接的服务器作为父节点）

• support for preventing cycles in the server graph.

• 多个服务器可以作为一个统一的系统来运行，用户可以把整个系统看作是简单的 client/server系统。

18

Server Databases

• 各服务器需要记录–所有其它的服务器–所有的用户 (yes, really all users!)–所有的频道 (chat groups)

• 每次该信息改变时，这个变化必须通告所有参与的服务器

19

Clients

• 客户端通过向任意一个服务器建立一个TCP连接，就连上了这个系统

• 客户端的注册通过发送：– (optional) 密码命令–绰号命令–用户名命令

20

Nicknames and user names

• 绰号是用户提供的一个标识符，它会随在每条用户发送的消息中– Wizard, kilroy, gargoyle, death_star,

gumby• 用户名有可能是假的， RFC931提供了一些机制来检查• 用户可以找出绰号对应的用户名

21

Collisions

• 如果一个客户端申请一个已在使用的绰号，那么服务器将会拒绝• 如果 2各客户端同时在不同的服务器上申请同一个用户名，有可能这两个服务器开始都不知道• 在这种情况下，这两个申请都会被拒绝

22

Nickname Collision

ServerA

ServerB

IRC Network

Client

I want to be satan

Client

I want to be satan

23

绰号的通告 Nickname Propagation

• 指定一个绰号的命令被从一个服务器传给所有的服务器（通过生成树）• The command is the same, but extra

information is added by the original server:– server name connected to client with nickname.– Hop count* from the server connected to the

client.*hop count is IRC server count (not IP!)

24

Problems

• 可扩展性：对于比较大的 IRC网络工作起来很好，但是需要扩展到更大的规模–当前，每个服务器都需要知道所有其它的服务器、频道、以及用户–服务器间路径的长度由管理员来确定，一棵优化的生成树应该自动生成的

25

Problems

• 支持一个带圈的网络（而不是生成树）会降低系统崩溃情况【路径变多：单点故障消失；消息的重复性】• 需要一个更好的机制来解决绰号冲突的问题

(everyone wants to be satan!)• 怎样来防止恶意服务器？ Current protocol

means that each server must assume neighbor server is correct. Bad guys could screw things up.