Outline

Understanding requirements of a chat system

Chat  What is the problem?
Issues and Ideas for Service Design  What are requirements?

Design of a multi-user chat system

1 2

What is the problem? Requirements

Functional requirements

A chat system that  Chat function

 Allows multiple users to talk to each others by text
by text

one-to-one, one-to-many, one-to-group

A test design to gain experiences on protocol  User management

Authentications
designs
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 for a chat system

Functional Issues
Protocol design
 Message types
 Message transmision (one vs. many groups)
System design  Scalability (how many users can be supported)
 Reliability (how to deal with failure)
 Security
Implementation
authentication

authorization

privacy
Test &
Validation

5 6

1
Message Types Message Types

Fixed-length header
Variable-length header
 Fast process, low overhead  Flexbile
 Large overhead

Good for lower layers’ protocol
 Tag header
 Not flexible
XML-based

0 128
<messageID>000</messageID><name>xxx</named>
<passwd>yyy</passwd>
Message ID Option
 Untagged header
User name
Using special characters to divide keywords
 E.g. \r\n in SMTP
Password
messageID:000\r\nname:xxx\r\npasswd:yyy

7 8

Message Types (2) Message transmission

Control messages
One channel or multiple channels

 Account management messages  Efficiency vs. simplicity
 Chat management messages
How to realize one-to-many talks?
 Group management messages  UDP

Data messages
UDP seems good but how to achieve reliability
 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 Scalability

Should we support more than one group?
How large a group do we want to support?
 Are groups dynamic or static?

Do we allow a user to create his/her own group?
 The larger a group is, the more group messages

Privacy/public group
we must send

Invite/Kick off
How many groups?
 What happens when there is nobody in a group?

Delete vs. not delete

What kind of service architecture will provide
 Can groups merge or split? efficient message delivery?

Based on the administration of admins
What kind of service architecture will allow

Do we need to receive the agreement of all members in the the system to support many users/groups?
group? How to?
 10000 access at a time is desirable
The more functional, the more complicated

11 12

2
Reliability Security

Authentication: do we need to know who each user

Does a user need to know (reliably) if all the is?
other users receives a message?  Login based on user name and password is required
 Password should be encrypted

What happens if a message is lost?

Authorization: do some users have more privileges
 resend? than others?

application level or at user level?  Who will be group administrators?

What happens when a user quits?
Privacy:
 Do messages need to be secure?
 Does everyone else need to know?

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/Server
Client
Server is well known.
Client Client

Life is easier for clients - don’t need to know
about all other clients.

Limited number of clients?
Client Server Client

Security is centralized.

Server might get overloaded?
Client
Client  Over 10000 connections at a time
Client

15 16

Server’s function Client’s functions

User management
Authentication

 Authentication

Sending request
 User information management
 Dealing with user requirement  Conversation

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

Message transmission

17 18

3
Peer-to-Peer Service Architecture Peer-to-Peer
Client
Client Client

No server, no client
 We are equivalent!
 No server overload
Client Client

No single point of failure
 But many points of failure!

Can deploy in a large scale

Cheap???
Client Client
Client

19 20

Peer-to-Peer (2) Server’s functions

Message routing is essential
 Broadcasting is not desirable

NONE
 Message routing may cause large delay

Message routing may be point-to-point

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 Hybrid Possibility

Joining P2P network Client

 Authentication
Client Client
 Get information of other nodes in the network

ID & IP MESSAGES

User information

Group information
 Create links to other nodes Client Server Client

Update information to/from other nodes
 User information CONTROL
 Group information Client
Client

Chatting Client

23 24

4
Hybrid Hybrid (2)

Clients connect to server and gather control
Still exit a single point of failure
information:  A secondary server may be a solution
 Login

Server load is reduced
 List of other clients.
 List of chat groups.

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 Client’s functions

User management
Authentication
 Authentication

Sending request
 User information management
 Group creation
 Dealing with user requirement
 Group join/disjoin

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

Conversation
 Group delete
 Group merge/split

27 28

Implementation issues Instant Messaging and Presence Protocol

(impp) working group (IETF)

Goals

Multi-processes vs. IO multiplexing vs. Multi-  Define protocols and data formats necessary to build an internet-scale end-
user presence awareness, notification and instant messaging system
thread  Specify how authentication, message integrity, encryption and access
control are integrated

Message parser
Homepage http://www.ietf.org/html.charters/OLD/impp-charter.html

RFC lists

Client’s GUI  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