Chat Issues and Ideas for Service Design
-
Upload
amena-calderon -
Category
Documents
-
view
58 -
download
1
description
Transcript of Chat Issues and Ideas for Service Design
![Page 1: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/1.jpg)
1
ChatIssues and Ideas for Service Design
Refs: RFC 1459 (IRC)
![Page 2: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/2.jpg)
2
Service Design Issues
• 假设我们要设计一个聊天系统• 我们来看一下在设计过程中需要解决的一些问题• 同时我们也会看到一些可能的系统架构
![Page 3: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/3.jpg)
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
![Page 4: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/4.jpg)
4
消息类型Message Types
• 一些可选项 Some options:–只是文本 text only–声音 audio–图像 images–任何东西,象邮件附件一样
anything (MIME)?
![Page 5: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/5.jpg)
5
消息的目的地Message Destinations
• 多用户聊天时,各条消息都发送给一个组 /群。–可以也发给单独的个人吗?–我们是否应该支持不只一个组 /群呢?
• 组是动态的还是静态的?• 如果一个组内没有人会怎样?• 组之间是否通信?• 组可以合并或者分裂吗?
![Page 6: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/6.jpg)
6
可扩展性• 我们想要支持多大的一个组(允许一个组内有多少用户)?• 支持多少个组?• 什么类型的服务架构可以提供有效的消息传递?• 什么类型的服务架构允许系统支持许多的用户 /组?
![Page 7: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/7.jpg)
7
可靠性• 用户需要知道所有其它人都收到了消息吗?• 如果一条消息丢失了会怎样?
–重发?应用层(聊天系统)还是用户自己来做?• 用户退出会怎样?
–其它人需要知道吗?
![Page 8: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/8.jpg)
8
安全性• 鉴权:我们需要知道各用户是谁吗?• 授权:一些用户是否需要有更多的特权?• 隐私:
–消息需要保密吗?–我们需要确保消息不会被伪造吗?
![Page 9: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/9.jpg)
9
Peer-to-Peer Service Architecture
Client
Client
Client
Client
Client
Client
ClientClient
![Page 10: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/10.jpg)
10
Peer-to-Peer Service Architecture (cont.)
各客户端与其它许多客户端直接对话• 谁最先运行呢?这种聊天服务有明确的地址(供客户端来查找)吗?• 我们可以记录多少个对端( peer ) /客户端• 如果两个客户端在同一台主机上,我们需要向该主机发送两遍同一条消息吗?
![Page 11: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/11.jpg)
11
Client/Server
Client
Client
Client
ClientClient
Client
Client
Client
Server
![Page 12: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/12.jpg)
12
Client/Server
• 服务器地址客户端都知道• 客户端比较简单——不需要知道所有其它的客户端• 客户端的数量有限制吗?• 集中式的安全机制• 服务器会过载( overloaded)吗?
![Page 13: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/13.jpg)
13
Hybrid Possibility
Client
Client
Client
ClientClient
Client
Client
Client
Server
CONTROL
MESSAGES
![Page 14: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/14.jpg)
14
混合方式 Hybrid
• 客户端连接到服务器、并收集控制信息:–其它客户端的列表–其它聊天组 /群的列表
• 消息是直接发送的(不通过服务器)–可以使用无连接协议 (UDP).
![Page 15: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/15.jpg)
15
Internet Relay Chat ( RFC 1459 )• IRC 是一个广泛使用的多用户聊天系
统 . –支持许多聊天组(频道)–大量的管理控制–分布式的服务架构– Still in use today, although WWW based
chat is now more common.
![Page 16: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/16.jpg)
16
Client
IRC Architecture
Client
Client
Client
ClientClient
Client
Client
Server Client
Client
Client
ClientClient
Client
Client
ServerServer
Server ServerClient
ClientClient
![Page 17: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/17.jpg)
17
Server Topology
• 服务器之间以生成树的方式相连(一个连通图的生成树是一个极小连通子图,它含有图中全部顶点,但只有足以构成一棵树的 n-1条边)– 任意 2个服务器之间只有一条路径– 服务器可以动态加入(比如选择它所连接的服务器作为父节点)
• support for preventing cycles in the server graph.
• 多个服务器可以作为一个统一的系统来运行,用户可以把整个系统看作是简单的 client/server系统。
![Page 18: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/18.jpg)
18
Server Databases
• 各服务器需要记录–所有其它的服务器–所有的用户 (yes, really all users!)–所有的频道 (chat groups)
• 每次该信息改变时,这个变化必须通告所有参与的服务器
![Page 19: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/19.jpg)
19
Clients
• 客户端通过向任意一个服务器建立一个TCP连接,就连上了这个系统
• 客户端的注册通过发送:– (optional) 密码命令–绰号命令–用户名命令
![Page 20: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/20.jpg)
20
Nicknames and user names
• 绰号是用户提供的一个标识符,它会随在每条用户发送的消息中– Wizard, kilroy, gargoyle, death_star,
gumby• 用户名有可能是假的, RFC931提供了一些机制来检查• 用户可以找出绰号对应的用户名
![Page 21: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/21.jpg)
21
Collisions
• 如果一个客户端申请一个已在使用的绰号,那么服务器将会拒绝• 如果 2各客户端同时在不同的服务器上申请同一个用户名,有可能这两个服务器开始都不知道• 在这种情况下,这两个申请都会被拒绝
![Page 22: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/22.jpg)
22
Nickname Collision
ServerA
ServerB
IRC Network
Client
I want to be satan
Client
I want to be satan
![Page 23: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/23.jpg)
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!)
![Page 24: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/24.jpg)
24
Problems
• 可扩展性:对于比较大的 IRC网络工作起来很好,但是需要扩展到更大的规模–当前,每个服务器都需要知道所有其它的服务器、频道、以及用户–服务器间路径的长度由管理员来确定,一棵优化的生成树应该自动生成的
![Page 25: Chat Issues and Ideas for Service Design](https://reader036.fdocuments.net/reader036/viewer/2022062400/56813472550346895d9b552a/html5/thumbnails/25.jpg)
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.