(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

HUYNH, et al. [Page 2]

Group 3: c2w protocol specification 02 2014

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

HUYNH, et al. [Page 3]

Group 3: c2w protocol specification 02 2014

++++ | 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:

HUYNH, et al. [Page 4]

Group 3: c2w protocol specification 02 2014

CRLF

Where 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 has recieved the request and The server will check this 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:

CRLF CRLF

CRLF CRLF

CRLF CRLF

.........

HUYNH, et al. [Page 5]

Group 3: c2w protocol specification 02 2014

CRLF CRLF

Where ist the username and is the availability of the user. is the sequence number of this send user list packet and 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

CRLF CRLF

CRLF CRLF CRLF

CRLF CRLF CRLF

.........

CRLF CRLF CRLF

Where and is the name of the movie, its IP and port. is the sequence number of this send user list packet and 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:

CRLF

Where 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".

HUYNH, et al. [Page 6]

Group 3: c2w protocol specification 02 2014

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:

CRLF

Where 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:

CRLF CRLF

Where and 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 has recieved the request and The server will check this 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 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 from the

HUYNH, et al. [Page 7]

Group 3: c2w protocol specification 02 2014

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 field SHOULD be leave EMPTY.

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

HUYNH, et al. [Page 8]

Group 3: c2w protocol specification 02 2014

+++ | type of message | Message format | +++ | Connecting_request | | | Connection_request accepted | empty | | Disconnection_request | empty | | Send_user_list | CRLF CRLF | | | CRLF .... | | | CRLF | | | CRLF | | | | | Send_movie_list | CRLF CRLF CRLF | | | CRLF CRLF | | | ............... CRLF | | | CRLF CRLF | | | | | Join_a_movie_room | | | Response_to_join_movie_room | empty | | Chat_message | CRLF | | Chat_message_distribution | CRLF 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.

HUYNH, et al. [Page 9]

Group 3: c2w protocol specification 02 2014

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) | |

Group 3: c2w protocol specification 02 2014

to all users in the main room. IF after 3s the server does not receive ACK, the server MUST resend the message.

User Server | | | Connection request (Request) | |X | | (Mes: Bob, Num: 32) | | | |(time out) | | | | Connection request (Request) | |>| | (Mes: Bob, Num: 32) | | | | | | Connection request accepted (Response) | || | (Bob) | | | | Send the user list (Response) | || | | | |

HUYNH, et al. [Page 11]

Group 3: c2w protocol specification 02 2014

| Send the movie list (Response) | || | | all users | | | | | Send the user list | | |>| | | (Mes:userlist) | | | | | | ACK | | |

Group 3: c2w protocol specification 02 2014

user(BOB) Server all users | | | | | | | chat message | | |>| | | ("hello") | | | | | | ACK | | || | | (BOB CRLF "hello") | | | | | | ACK | | |

Group 3: c2w protocol specification 02 2014

User Server | | | | | Join a movie room (Response) | |>| | (Mes: The god father) | | | | ACK | || | | (Mes:userlist) | | | | | | ACK | | |

Group 3: c2w protocol specification 02 2014

and the mainroom to update their status (not shown in this figure)

User Server | | | | | Leave movie room (Request) | |>| | | | | | ACK | |

Group 3: c2w protocol specification 02 2014

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) | | Disconnection request (Request) | |>| | | | Disconnection request (Request) | |

Group 3: c2w protocol specification 02 2014

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) | | Check availbility (Request) | |>| | | | ACK | | X| | | |(time out) | | Check availbility (Request) | |>| | | | 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

HUYNH, et al. [Page 17]

Group 3: c2w protocol specification 02 2014

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

HUYNH, et al. [Page 18]