Objectives :

Socket programming in python

Design and document an application-layer protocol.

Develop a client-server network application using stream socket API ( TCP ) of Python

that implements the protocol you documented.

General Instruction

Make sure to use TCP as the transport protocol

Description

The application you will develop is intended to support clients ability to store notes on server,

and to request notes that have certain properties.

Client should be able to make the following requests:

1. Setup a connection with the server

2. Send different types of request messages through established connection:

a. POST

b. GET

c. PIN/UNPIN

d. CLEAR

e. DISCONNECT

Server should be able to do the following:

Accept multiple requests for connections

Maintain an appropriate data structure (notes dictionary or board) that holds data

received from clients

Process messages received from client:

If message is POST , server will have to store the note described in

part of the message.

If message is GET , server has to send to client all notes stored in the

dictionary that satisfy properties described in .

If message is PIN , server must pin all notes relevant to .

If message is UNPIN , server must unpin all notes relevant to .

If message is CLEAR, server must forget all notes which are not pinned.

If message is DISCONNECT, server will disconnect the connection with the

client.

Definitions:

is similar to post-it note (colored rectangular piece of paper containing a string): If a

client would like to POST a note, it must completely defined by the coordinates of lower-left

corner, width, height, color, message and status (pinned/unpinned)

Example:

POST 2 3 10 20 white Meeting next Wednesday from 2 to 3

POST 6 6 5 5 red Pick up Fred from home at 5

is a pair of integers, describing x and y coordinates of a point on the board.

When notes are originally posted, they are not pinned. To change the status of a note, a client

can use PIN or UNPIN command. For example,

PIN 4,4

will pin all notes that contain the given pin coordinates. In

the example above the first note will be pinned

PIN 7,7

will change the status of both notes to pinned.

The meaning of UNPIN is obvious. However, remember that a note can be pinned by more than

one pin. So, UNPIN command does not necessary changes the status of a note.

field in GET request may take two values

1. PIN

Example:

GET PINS

The above message forces the server to supply a client with coordinates of all pins.

2. It could have the following general format:

color= contains= referesTo=

Such a parameter will force the server to supply the client with information of all notes of

the particular color that contain point and has substring in the content.

If one of the criteria is missing the semantics of request is ALL (for example, no color in

GET means ALL colors)

Example:

GET color=white

will force the server to supply a client with all white notes on the board.

GET contains= 4 6

will force the server to supply a client with all notes that contain point with coordinates

(4,6).

GET contains= 4 6 refersTo=Fred

will force the server to supply a client with all notes that contain point with coordinates

(4,6) and have substring Fred in the content.

Implementation requirements.

Server is a multi-process python console application that has multiple command line arguments

and starts with empty notes dictionary. The arguments are in order:

, ,, ,

2>,...,.

For example, if implementation of server is in file SBoard.py , then to start server in command

line one can execute

>python SBoard.py 4554 200 100 red white green yellow

which starts the server ready to accept connections on port 4554, supporting the board 200

units wide and 100 units tall, accepting notes of the colors red, white, green or yellow (with red

being default color).

Every new client connected to the server will receive a list of available colors, and the dimension

of the board upon successful connection. Servers response to GET type of message is

obvious. Servers response to POST type of messages has to confirm the receipt of the note (or

send back an ERROR message). Error handling responsibilities naturally split between server

and client and must be described in your document. Also note that the board exists only

between server start and shutdown, and does not need to be stored.

Client has to provide a text menu to the user for different functionalities supported

1-connect

2-disconnect

3-POST

4-GET

5-PIN

6-UNPIN

Client should show the result of each request to the user.

Upon choosing any of the options by the user, the client program should ask the user for more

information. For example, If the user chooses 1, the program should ask the user to provide

server address and port numbers. If the user chooses 3, the program should ask the user to

enter the message to be posted to the server.

Documentation

The documentation should follow the format of an RFC document (e.g,

https://tools.ietf.org/html/rfc2616 )

Specifically it should contain the following information:

description of your protocol including

format of messages sent by client and server

Format of request messages

Format of response messages (note that the format of is not

suggested in this document)

synchronization policies: describes your design decisions for having a

multi-process server.

Error handling mechanism on server and client; how the client and server react to

errors. It should explain what messages are communicated between client and

server in case of an error. What messages are reported to the user in case of an

error. For example the format of a post message should be checked by the client.

Or if the format of a message is correct, but it results in an error on the server

(e.g., pinning a note that does not exist) the server should reply with appropriate

error message. The different cases should be explained in your documentation.

Bonus

Make the client side a GUI-based application

Text field to provide IP address of the server

Text field to provide port number

Connect/Disconnect button

Text area to type in text to be sent to server and POST button

GET button with dialogue to enter required properties

PIN/UNPIN button with a dialogue to supply coordinates