A Simple Chat Protocol

(c) GROUP 3, 2014 L.
HUYNH
M. MERTAH
F. VIOSSAT
G. KACMAZ
Telecom Bretagne
02 2014
Group 3: c2w protocol specification proposal
Abstract
This document defines a protocol for the c2w application between
clients and a movie server . The goal of this protocol is to
establish a communication between user and server. Users will be
able to connect to a server, chat with other users in the main room (
public chat), select and enter into a movie room to watch streams and
chat with users inthe same room (movie room chat).
HUYNH, et al. [Page 1]
Group 3: c2w protocol specification 02 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Server Configuration . . . . . . . . . . . . . . . . . . . . . 9
5. Example scenario . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Scenario 1: Invalid login . . . . . . . . . . . . . . . . 10
5.2. Scenario 2: Success login . . . . . . . . . . . . . . . . 10
5.3. Scenario 3: Chatting in the main room . . . . . . . . . . 12
5.4. Scenario 4: Watch the movie . . . . . . . . . . . . . . . 13
5.5. Scenario 5: Stop watching a movie . . . . . . . . . . . . 14
5.6. Scenario 6: Deconnect . . . . . . . . . . . . . . . . . . 15
5.7. Scenario 7: Availability check . . . . . . . . . . . . . . 17
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The goal of this protocol is to allow communication between clients
and server. This protocol have a binary header to define the command
message. Some type of commande message has a text format.
This protocol only handles the information stream between the clients
and server. The video stream is handled orther protocol.
Clients can use either UDP or TCP to exchange command messages with a
server.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Packet format
The Messages exchanged between the server and the client has the same
format as show in figure Figure 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+++++++++++++++++++++++++++++++++
| CODE | NUMBER | DATA LENGTH |
+++++++++++++++++++++++++++++++++
. .
. Message Data .
. .
| |
+++++++++++++++++++++++++++++++++
Figure 1
CODE (8bits):
This field containe a binary code uses to define the type of
message. The following table represent all codes,the corresponded
message qnd the source (the sender). Each message type has
different uses which will be explained in the message data
++++
| Code | Type of message | Source |
++++
| 0000 | Connecting request | User |
| 0001 | Connection request accepted | Server |
| 0010 | Disconnection request | User/Server |
| 0100 | Send user list | Server |
| 0101 | Send movie list | Server |
| 0110 | Join a movie room | User |
| 0111 | Response to join movie room | Server |
| 1000 | Chat message | User |
| 1001 | Chat message distribution | Server |
| 1010 | Leave movie room | User/Server |
| 1011 | Error message | Server |
| 1100 | ACK | User/Server |
| 1101 | Check availbility | Server |
++++
Table 1: Meaning of the code field
NUMBER field (8 bits):
This field contains the number of the message exchangerd between
the user and the server.The role of this field is to indicate the
number of message in the ack request.
DATA LENGTH field (16 bits):
This field contains the total length of the message Data. For UDP
protocol, user list and movie list will be send in more than one
packet, the number of packet is defined in the message data. It
MUST NOT exceed 65503 (65535 8 byte UDP header 20 byte IP
header 4 byte this protocol header
MESSAGE DATA field (variable length):
This field contains the ASCII message corresponding to each type
of message. The message is different depends on type of message
which presented by the CODE. The message format for each type of
message is:
Connection request:
Send by the client to ask for connection. The message format:
<Username> CRLF
Where <Username> is the username the client want to sign up
for. The server MUST reply with and ACK to confirm that server
has recieved the request and The server will check this
request. Server MAY reply with a "Connection request accepted"
message or an "Error message". After that, server MUST listen
for the ACK, if not, server will resend the message.
Disconnection request:
Can be sent by the client or the server.
Send by the client to ask for disconnection. The message field
SHOULD be leave EMPTY
The server MUST reply with and ACK to confirm that server
request. Server MUST reply with an "Disconnection request"
and wait for an ACK from the client. If server does not
recieved an ACK server will resend the "Disconnection
request". Server will delete this user if he recieved an
ACK or after sending "Disconnection request" 3 times.
Send by the server either to confirm the disconnection request
or to disconnect a client. The message field SHOULD be leave
EMPTY.
The client must reply with and ACK and stop send any data to
the server. If the server does not recieved an ACK server
will resend the "Disconnection request". The server will
delete this user if he recieved an ACK or after sending
"Disconnection request" 3 times.
Send user list:
Send by the server to update the userlist of the client. It
MUST follow this format:
<Seq> CRLF <total> CRLF
<Username1> CRLF <Availability1> CRLF
<Username1> CRLF <Availability1> CRLF
.........
<UsernameN> CRLF <AvailabilityN> CRLF
Where <Username1> ist the username and <Availbility1> is the
availability of the user. <Seq> is the sequence number of this
send user list packet and <total> is the number of packet Every
time the client recieved this message, the client must use this
infomation to display it userlist. The client MUST reply this
message with an ACK.
Send movie list:
Send by the server to update the movie list of the client. It
MUST follow this format
<Seq> CRLF <total> CRLF
<movie1> CRLF <IP1> CRLF <port1> CRLF
<movie2> CRLF <IP2> CRLF <port2> CRLF
.........
<movieN> CRLF <IPN> CRLF <portN> CRLF
Where <movie1> <IP1>and <port1> is the name of the movie, its
IP and port. <Seq> is the sequence number of this send user
list packet and <total> is the number of packet Every time the
client recieved this message, the client must use this
infomation to display and store the movielist. The client MUST
reply this message with an ACK.
Join a movie room:
Send by the client to ask to join a movie room. The message
format:
<movie name> CRLF
Where <movie name> is the movie name the client want to watch.
The server MUST reply with and ACK to confirm that server has
recieved the request and The server will check this request.
Server MAY reply with a "Response to join movie" message or an
"Error message". After that, server wait for an ACK, if not,
server will resend the message. Afterthat, the server will
send the "send the user list".
Response to join movie room:
Send by the server to confirm the access. The message field
SHOULD be leave EMPTY
Chat message:
Send by the client in a certain room. The message format:
<message> CRLF
Where <message> is the message the client want to send. The
server MUST reply with and ACK to confirm that server has
recieved the request and The server will check this user to
find out his room. The server will send a chat message
distribution to all user in the same room with the client.
Chat message distribution:
Send by the server to distribute a chat message. The message
format:
<username> CRLF <message> CRLF
Where <username> and <message> is the user name and his message
he want to send. The client MUST reply with and ACK to confirm
that client has recieved the request. The server will re send
2 more time if the server recieved no ACK from a Client. After
the third time out, he will consider this client disconnected.
Leave movie room:
Send by the client to ask to leave a movie room. The message
field SHOULD be leave EMPTY.
The server MUST reply with and ACK to confirm that server
request. Server MUST reply with an "Leave movie room" and
wait for an ACK from the client. If server does not
recieved an ACK server will resend the "Leave movie room".
If the server recieved an ACK, the server modifies this
clients room to the main room, change his availability and
send "Send the movie list" and "Send the user list". The
server will resend 2 more time "Leave movie room" if the
server recieved no ACK from a Client. After the third time
out, he will consider this client disconnected.
Send by the server either to confirm the leave a movie room
request or to disconnect a client from a movie. The message
The client must reply with and ACK and stop send any data to
the server. If the server does not recieved an ACK from the
client. Server will resend the "leave a movie room"
request. The server will delete this user if he does not
recieve an ACK after sending "Disconnection request" 3
times. If the server recieved an ACK, the server modifies
this clients room to the main room, change his availability
and send "Send the movie list" and "Send the user list".
ACK:
Send by the client or the server to confirm the reception of a
message, especially when using UDP connection. The message
Error message:
Send by the server to explain the error. It contains 1 byte
corresponds to these error
+++
| Value | Error |
+++
| 1 | Invalid message |
| 2 | Username already existent |
| 3 | Not connected |
| 4 | Movie none existent |
+++
Note: the error 3: not connected is send when the server has consider
client disconnected but the client think he still connected and send
message to the server.
Table 2: Error code
Check availability:
The server will check if the user still in the system every 1
minute with the Check availability message. If the client does
not reply this message with ACK the server will consider him
deconnected and delete that username and ip in all of his
table.
This is a summary of message format
+++
| type of message | Message format |
+++
| Connecting_request | <Username> |
| Connection_request accepted | empty |
| Disconnection_request | empty |
| Send_user_list | <seg>CRLF <total> <Username1> CRLF |
| | <Availability1> CRLF .... |
| | <UsernameN> CRLF <AvailabilityN> |
| | CRLF |
| | |
| Send_movie_list | <seg>CRLF <total> CRLF<movie1> CRLF |
| | <IP1> CRLF <port1> CRLF |
| | ............... <movieN> CRLF <IPN> |
| | CRLF <portN> CRLF |
| | |
| Join_a_movie_room | <movie name> |
| Response_to_join_movie_room | empty |
| Chat_message | <message> CRLF |
| Chat_message_distribution | <username> CRLF <message> CRLF |
| Leave_movie_room | empty |
| | |
| Error_message | It contains 1 byte corresponds to |
| | these error |
| | |
| ACK | empty |
| Check availbility | empty |
+++
Table 3: Format of the message data correspond to each type of
message
The server MUST always reply to a request, either with a
corresponding response or with a Error message
3. Reliability
This protocol require and ACK system to confirm the receiption of
message. In order not to overload servers, clients SHOULD wait at
least 2 seconds before resending a request.
4. Server Configuration
The server MUST maintain a local data base mapping usernames to IP
addresses and port of the client and the room the user is currently
in.
5. Example scenario
5.1. Scenario 1: Invalid login
The client try to connect to the server with a username already
exist. The server MUST check it userlist and responds with an error
message with the error code 2 (Username already existant).
User Server
| |
| Connection request (Request) |
|>|
| (Alice) |
| |
| ACK (Response) |
|<|
| () |
| |
| |
| Error message (Response) |
|<|
| (2) |
| |
| ACK (Response) |
|>|
| |
| |
| |
Figure 2
5.2. Scenario 2: Success login
The client try to connect to the server. At first, his request fail
to reach the server, so after time out, he resend it. After the
server checks its userlist and replies with the message: Connection
request accepted but it fail to reach the client. After time out
without recieving ACK from the client, the server resend the
Connection request accepted. This time the server receives the ACK
The server update the user list (add the new user in the list).
After that, to display the Mainroom, the client send Main room
element request and the server respond with Send the user list and
Send the movie list. The client MUST replied with ACK to each
message of the server. The server will also send the new user list
to all users in the main room. IF after 3s the server does not
receive ACK, the server MUST resend the message.
User Server
| |
|X |
| (Mes: Bob, Num: 32) |
| |
|(time out) |
| |
|>|
| (Mes: Bob, Num: 32) |
| |
| |
| Connection request accepted (Response) |
|<|
| (Num: 33) |
| |
| ACK (Response) |
|X |
| (Num:34) |
| |
| |
| Connection request accepted (Response) |
|<|
| (Num: 33) |
| |
| ACK (Response) |
|>|
| (Num: 33) |
| |
| |
| Main room element request (Request) |
|>|
| (Bob) |
| |
| Send the user list (Response) |
|<|
| (Mes:userlist) |
| |
| ACK (Response) |
| >|
| |
| |
| Send the movie list (Response) |
|<|
| (Mes:movielist) |
| |
| ACK (Response) |
|>|
| | all users
| | |
| | Send the user list |
| |>|
| | (Mes:userlist) |
| | |
| | ACK |
| |<|
| | |
Figure 3
5.3. Scenario 3: Chatting in the main room
The client (whose username is Bob) is in the main room, he send a
chat message for all user in the main room. The server reply with an
ACK to confirm that he have received the message. According to the
Ip of the client, the server look at its user table and find out the
client is in the mainroom. He foward the message to all the user who
are in the mainroom. Each user MUST reply this message with ACK. If
the server doesnt received ACK after 10s, he will resend the
message.
user(BOB) Server all users
| | |
| | |
| chat message | |
|>| |
| ("hello") | |
| | |
| ACK | |
|<| |
| | |
| | |
| | Chat message distribution |
| |>|
| | (BOB CRLF "hello") |
| | |
| | ACK |
| |<|
| | |
| | |
Figure 4
5.4. Scenario 4: Watch the movie
The client (whose username is Bob) is in the main room, to change
into the movie room the client send a Join a movie room message to
the server. According to the Ip of the client, the server look at
its user table and find out the client is in the mainroom. The
server change the availability of this user and add this user to the
table of this movie. He reply with "Response to join movie" and
"Send user list" messages. Each Message MUST follow with an ACK from
the client. The server will send the "Send user list" messages to
every user in that room and the mainroom to update their status (not
shown in this figure)
User Server
| |
| |
| Join a movie room (Response) |
|>|
| (Mes: The god father) |
| |
| ACK |
|<|
| |
| |
| "Response to join movie" (Response) |
|<|
| |
| |
| ACK |
|>|
| |
| |
|<|
| (Mes:userlist) |
| |
| ACK |
|>|
| |
| | other user
| | |
| | Send the user list |
| |>|
| | (Mes:userlist) |
| | |
| | ACK |
| |<|
| | |
Figure 5
5.5. Scenario 5: Stop watching a movie
The client is in the movie room. To come back to the main room, the
client send the message "Leave movie room" The server reply with ACK
to confirm he has received and use the ip of the client to find his
user name and look for the room where he is in. The server modifies
this clients room to the main room and change his availability The
server replies with 2 messages "Send user list" and "Send movie
list", each message MUST follow by an ACK by the client.The server
will send the "Send user list" messages to every user in that room
and the mainroom to update their status (not shown in this figure)
User Server
| |
| |
| Leave movie room (Request) |
|>|
| |
| |
| ACK |
|<|
| |
| Leave movie room (response) |
|<|
| |
| |
| ACK |
|>|
| |
| |
|<|
| (Mes:userlist) |
| |
| ACK (Response) |
|>|
| () |
| |
| |
| Send the movie list (Response) |
|<|
| (Mes:movielist) |
| |
| ACK (Response) |
|>|
| () |
Figure 6
5.6. Scenario 6: Deconnect
The client is in the main room. Sign out, the client send the
message "Disconnection request" The server reply with ACK to confirm
he has received wait for an ACK form the client. After received an
ACK from the client, the server delete all data corresponds with this
IP. The client consider himself deconnected after send ACK to the
server. If the server does not received ACK from the client, after
time out he will resend ACK. After the third time send ACK, if he
does not received response, he consider client deconnected.The server
will send the "Send user list" messages to every user in that room
and the mainroom to update their status (not shown in this figure).
User Server
| |
| |
| Disconnection request (Request) |
|>|
| |
| ACK |
| X|
| |
| |
|(time out) |
|>|
| |
|<|
| |
| ACK (Response) |
|X |
|(disconnected) |
| (time out)|
|<|
|(disconnected/drop packet) |
| |
| (time out)|
|<|
|(disconnected/drop packet) |
| |
| (time out)|
| (delete user)|
Figure 7
5.7. Scenario 7: Availability check
The Server send the "check availability" message to all user every 10
minute All client MUST reply with ACK. If the server does not
receive ACK from a user the server will send the "check availability"
message 2 more time. If still not receive any ACK, he will consider
this client disconnected. The server will send the "Send user list"
messages to every user in that room and the mainroom to update their
status (not shown in this figure)
Server Client
| |
| |
| Check availbility (Request) |
|X |
| |
| |
| |
| (time out) |
|>|
| |
| ACK |
| X|
| |
|(time out) |
|>|
| |
| ACK |
| X|
| |
|(time out) |
|(delete user) |
Figure 8
6. Conclusion
We have proposed a protocol which realise all function of a c2w
application and comparative with both UDP and TCP
Authors Addresses
Le Duy HUYNH
Telecom Bretagne
Brest,
France
Email: le.huynh@telecombretagne.eu
Mohamed Ali MERTAH
Telecom Bretagne
Brest,
France
Email: mohamed.mertah@telecombretagne.eu
Fabien VIOSSAT
Telecom Bretagne
Brest,
France
Email: fabien.viossat@telecombretagne.eu
Gizem KACMAZ
Telecom Bretagne
Brest,
France
Email: gizem.kacmaz@telecombretagne.eu

A Simple Chat Protocol

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

A Simple Chat Protocol

Transféré par

Droits d'auteur :

Formats disponibles

(c) GROUP 3, 2014 L.

Vous aimerez peut-être aussi