Outline

Chat
Issues and Ideas for Service Design

Understanding requirements of a chat system
What is the problem? What are requirements?

Design of a multi-user chat system

1

2

What is the problem?
A chat system that
Allows multiple users to talk to each others by text

Requirements
Functional requirements Chat function
by text one-to-one, one-to-many, one-to-group

A test design to gain experiences on protocol designs

User management
Authentications Acount management Group management

None-functional requirements 10000 accesses at a time
How to achieve?

Cost
three workers in one month

Other options File transfer, voice chat, atmosphere transfer
3 4

Design steps
Protocol design

Protocol design for a chat system
Functional Issues
Message types Message transmision (one vs. many groups) Scalability (how many users can be supported) Reliability (how to deal with failure) Security
authentication authorization privacy

System design

Implementation Test & Validation

5

6

1

Message Types
Fixed-length header
Fast process, low overhead
Good for lower layers’ protocol

Message Types
Variable-length header
Flexbile Large overhead Tag header
128

Not flexible
0 Message ID User name Password Option

XML-based <messageID>000</messageID><name>xxx</named> <passwd>yyy</passwd>

Untagged header
Using special characters to divide keywords
E.g. \r\n in SMTP

messageID:000\r\nname:xxx\r\npasswd:yyy
7 8

Message Types (2)
Control messages
Account management messages Chat management messages Group management messages

Message transmission
One channel or multiple channels
Efficiency vs. simplicity

How to realize one-to-many talks?
UDP
UDP seems good but how to achieve reliability

Data messages
Conversation messages

TCP
You must create multiple TCP connections and send to individually “Create one, use forever” or “Create whenever want”

9

10

Group management
Should we support more than one group?
Are groups dynamic or static?
Do we allow a user to create his/her own group? Privacy/public group Invite/Kick off

Scalability
How large a group do we want to support?
The larger a group is, the more group messages we must send

What happens when there is nobody in a group?
Delete vs. not delete

Can groups merge or split?
Based on the administration of admins Do we need to receive the agreement of all members in the group? How to?

How many groups? What kind of service architecture will provide efficient message delivery? What kind of service architecture will allow the system to support many users/groups?
10000 access at a time is desirable

The more functional, the more complicated
11 12

2

Reliability
Does a user need to know (reliably) if all the other users receives a message? What happens if a message is lost?
resend?
application level or at user level?

Security
Authentication: do we need to know who each user is?
Login based on user name and password is required Password should be encrypted

Authorization: do some users have more privileges than others?
Who will be group administrators?

What happens when a user quits?
Does everyone else need to know?

Privacy:
Do messages need to be secure?
Functionality vs. efficiency

What happens when a user PC is down?

Do we need to make sure messages cannot be forged?

13

14

Client/Server
Client Client Client

Client/Server
Server is well known. Life is easier for clients - don’t need to know about all other clients. Limited number of clients? Security is centralized. Server might get overloaded?
Over 10000 connections at a time

Client

Server

Client

Client Client Client

15

16

Server’s function
User management
Authentication User information management Dealing with user requirement

Client’s functions
Authentication Sending request
Conversation Group creation Group join/disjoin Group delete Group merge/split

Group management
Group creation Group join/disjoin Group delete Group merge/split

Message transmission
17 18

3

Peer-to-Peer Service Architecture
Client Client Client

Peer-to-Peer
No server, no client
We are equivalent! No server overload

Client

Client

No single point of failure
But many points of failure!

Client Client

Client

Can deploy in a large scale Cheap???

19

20

Peer-to-Peer (2)
Message routing is essential Broadcasting is not desirable Message routing may cause large delay
Message routing may be point-to-point

Server’s functions
NONE

How to maintain a group? Where to keep information of a group?
At one client or multiple clients

Authentication How to identify a user? How to match? Name, ID, IP address How to gain reliability between users? How do I know who you are?
Solution: Exchange of public keys, Friend of friend is friend, Responsibility between users

Who’s on first? Is there a well known address for the service?

21

22

Client’s functions
Joining P2P network
Authentication Get information of other nodes in the network
ID & IP User information Group information

Hybrid Possibility
Client Client
MESSAGES

Client

Create links to other nodes

Client
CONTROL

Server

Client

Update information to/from other nodes
User information Group information

Client Client Client
23 24

Chatting

4

Hybrid
Clients connect to server and gather control information:
Login List of other clients. List of chat groups.

Hybrid (2)
Still exit a single point of failure
A secondary server may be a solution

Server load is reduced

Messages are sent directly (not through server).
Could use connectionless protocol (UDP or transaction based TCP). How to authenticate between users?
25 26

Server’s functions
User management
Authentication User information management Dealing with user requirement

Client’s functions
Authentication Sending request
Group creation Group join/disjoin Group delete Group merge/split

Group management
Group creation Group join/disjoin Group delete Group merge/split
27

Conversation

28

Implementation issues
Multi-processes vs. IO multiplexing vs. Multithread Message parser Client’s GUI

Instant Messaging and Presence Protocol (impp) working group (IETF)
Goals
Define protocols and data formats necessary to build an internet-scale enduser presence awareness, notification and instant messaging system Specify how authentication, message integrity, encryption and access control are integrated

Homepage http://www.ietf.org/html.charters/OLD/impp-charter.html RFC lists
A Model for Presence and Instant Messaging (RFC 2778) Instant Messaging / Presence Protocol Requirements (RFC 2779) Date and Time on the Internet: Timestamps (RFC 3339) Common Profile for Presence (CPP) (RFC 3859) Common Profile for Instant Messaging (CPIM) (RFC 3860) Address Resolution for Instant Messaging and Presence (RFC 3861) Common Presence and Instant Messaging: Message Format (RFC 3862) Presence Information Data Format (PIDF) (RFC 3863)

29

30

5