代写COMP 3331、C/Java/Python编程代写

日期：2022-04-22 08:06

COMP 3331/9331

Assignment T1 2022

Online Discussion Forum

All details are in the specification

• READ THE SPECIFICATION

• READ THE SPECIFICATION (AGAIN)

• Information about deadlines, file names, submission instructions,

marking guidelines, example interactions and various other specifics

are in the specification

• Choice of programming languages: C, Java, Python

• This talk provides a high-level overview

Client Server Architecture

• Server

• Always on

• Responsible for managing the discussion forum

• Maintains state about the forum

• Implements a request/response API for interacting with client(s)

• Prints informative updates at the terminal

• Client

• Allows a user to interact with the discussion forum

• Interaction is through the command line terminal

• Transport Protocol

• UDP (for most interactions) + TCP (only for implementing the file transfer aspects of

UPD and DWN commands)

Execution

• Client(s) and Server executed on the same machine in different terminals

• Server

• Command line arguments:

• Server port (use a value greater than 1023 and less than 65536)

• same port number for UDP and TCP as they are distinct ports

• Executed first – waits for client(s) to connect

• Forum is empty at start-up – no threads, no messages, no files, no users logged in

• Server will keep executing forever

• Client

• Command line arguments:

• Server port number (should match the first argument for the server)

• Let the OS pick an ephemeral port

• Client should send UDP segments to (“127.0.0.1”, server port) and initiate TCP connection

(for file transfer) to (“127.0.0.1”, server port)

Two Configurations

• One client at a time (14 marks – 70% of the assignment marks)

• At any given time only one client will interact with the server

• Simple sequential interaction between client and server

• Should not require multi-threading

• Multiple clients can connect sequentially – i.e., one client connects, executes some

commands, quits, second client connects, executes commands, quits, etc.

• You will have to define and manage a number of data structures (more on this later)

• You must design your own application layer protocol

• This includes the syntax/semantics of the messages exchanged between the client and server

and the actions to be taken upon receiving each message

• Non-CSE Students may chose to only implement functionality for this configuration

• MUST request approval – check spec for details

• Note that the server will not be stopped between tests for the two configurations

Two Configurations

• Concurrent multiple clients (6 marks – 30% of the assignment marks)

• Client program will very likely require no changes

• Server program must interact with multiple clients

• We recommend a multi—threaded approach

• Many implementation approaches possible – we do not mandate a particular approach

• Possible for multiple threads to communicate using a single UDP socket, so no need to create

multiple sockets

• The interactions with an individual client should still be sequential as in the first configuration

• However, the discussion forum state is now updated by multiple clients

• Client A adds a new message to a thread. Following this, when Client B reads the thread, client A’s message

should be viewable

• You may assume that each interaction (10 commands + authentication) with a client is “atomic”

• E.g.: Client A initiates an interaction to add a new message to a thread. While the server is processing this

interaction, it cannot be interrupted by a command from another client (B). Client B’s command will be

acted upon after the command from client A is processed

• For UPD and DWN – this means the server can either be sending/receiving a file to/from one client at a

given time, thus only needs to manage one TCP connection at any given time

• You must be particularly careful about managing multiple threads and how they access the

shared state (data structures, files, etc.) for the message board

User Authentication

• A credentials file will be available in the server working directory

(example is on the assignment page)

• The client will first authenticate the user

• Ask user to enter username

• If username matches with one of the entries in the credentials file, the user is

requested to enter the password

• If password matches, authentication successful

• If password doesn’t match, the user is asked to enter username again (no limit on

number of attempts)

• If username does not match it is assumed this is a new user and user is asked

to enter a new password

• User is authenticated and a new entry (username & password) is created in the

credentials file

Discussion Forum Operations

• Should support 10 commands

• User is prompted to enter one of the commands

• Basic error checking for syntax, appropriate arguments, etc. should be

implemented

• NOTE: We are more interested in observing if you have implemented the “normal”

functionality, so our tests for error checking will be limited and won’t include bizarre edge

cases

• Some of these errors can be detected on the client-side and will not require communication

with the server

• 8 commands excluding UPD and DWN use UDP for communication

• UPD and DWN – only the file transfer should happen over TCP, other interactions

over UDP

• UDP segments may be lost, so your application must implement mechanisms to

deal with occasional packet loss

• Keep it simple, use ideas discussed in the reliable data delivery lecture

Commands

• CRT – Create thread

• CRT threadtitle

• Create a new thread – represented as a text file (threadtitle), update state

information about active threads and thread creators

• MSG – Post message

• MSG thread message

• Add message to the thread – update the thread file (message number,

username, message)

• DLT – Delete message

• DLT thread messagenumber

• A message can only be deleted by the original creator (error if condition not

met)

• Delete message – update the thread file (remove the message and update

message numbers if required)

Commands

• EDT – Edit message • EDT threadtitle messagenumber message

• A message can only be edited by the original creator (error if condition not met)

• Edit the thread – update the thread file (only update message)

• LST – List threads • LST

• List all active threads

• Read data structure that stores this information and send it to client

• RDT – Read thread • RDT threadtitle

• Display all messages contained in thread

• Read the corresponding thread file and send relevant information to client

Commands

• RMV – Remove thread

• RMV threadtitle

• A thread can only be removed by the original creator (error if condition not

met)

• Remove all state associated with the thread (thread file, uploaded files)

• XIT – Exit

• XIT

• User quits

• Update state about active users

Commands

• UPD – Upload file • UPD threadtitle filename

• Use UDP for all communication except for file transfer which should use TCP

• Create filename in server working directory

• Server opens a welcome socket (@ server port – UDP and TCP ports are distinct)

• Client should initiate TCP connection with server

• Transfer file over TCP connection

• Close TCP connection

• All file data received from client stored in the file in the serve working directory

• Update thread file with information about file (username uploaded filename)

• DWN – Download file • DWN threadtitle filename

• Create filename in client working directory and store all file data received from server

• As with UPD use UDP for all communication except file transfer which should use TCP

• Follow the steps similar to UPD

Data Structures

• Server must maintain certain state information about the forum

including number of threads, thread creators, messages per thread,

message creators, online users, etc.

• Server will also have to manage several files – one for each thread

and files uploaded by users

• Proper design of data structures is essential to ensure all functionality

can be achieved

• Be careful about accessing the data structures across multiple threads

• Avoid arbitrary upper limits for variables

• Dynamic memory allocation is recommended

How to start and progress

• Focus on first configuration

• Get the client and server to exchange UDP segments

• Implement authentication

• Implement one command, test it thoroughly, move to the next

• Suggest the following order: XIT, CRT, LST, MSG, RDT, EDT, DLT, RMV

• Get the client to setup a TCP connection with the server and test data transmission over the

connection

• Implement UPD, DWN with the file transfer happening over TCP

• Once all individual commands are done and tested, then make sure you test extensive interaction

with a single client (meaningful combination of commands)

• Next progress to second configuration – multi-threading

• STRONGLY SUGGEST TO DEVELOP YOUR IMPLEMENTATION IN VLAB ENVIRONMENT (NOT ON

YOUR NATIVE MACHINE)

• Added benefit – CSE accounts are backed up

Report

• Program design

• Data structures

• Details of the application layer protocol

• Trade-offs considered

• Point out issues if program does not work under certain

circumstances

• Refer to all borrowed code

Testing

• Test, Test, Test

• Server and client(s) executing on same machine but different working directories

• Emphasis on correct behaviour

• Basic error checking

• MUST Test In VLAB environment and through command line

• If we cannot run your code, then we cannot award you any marks

• Your assignment will be MANUALLY marked by your tutors

• Client and server must display meaningful messages at the terminal

• Extensive examples are available at the end of the spec

• You are NOT required to use the exact same text

• Detailed marking rubric is available in specification

• SYSTEMATIC DEBUGGING + UNIT FUNCTIONS

Plagiarism

• DO NOT DO IT

• Both parties involved are considered guilty

• DO NOT POST YOUR CODE ON A PUBLICLY ACCESSIBLE REPOSITORY

HOSTING SERVICE (e.g., Github)

• EQUIVALENT TO PROVIDING YOUR CODE TO THE ENTIRE WORLD

• If caught

• You will receive zero marks (and there may be further repercussions if this is

not your first offence)

• Your name will be added to the school plagiarism register

• Every term I have had to do the above for a small group of students

• Would be nice to not have to do it in this term

Non-CSE Students

• Must be enrolled in a non-CSE program (double degree that includes

a CSE major does not qualify)

• Can opt for non-CSE option

• MUST request permission to do so by 5pm, 18th March by emailing

cs3331@cse.unsw.edu.au

Resources

• Many program snippets are on the web page

• Including multi-threading code snippets

• Your socket programming experience in Labs 2 and 3 will be useful

• Repository of resources is here

Seeking Help

• Assignment specific consults (for all 3 programming languages) from

Weeks 7-10

• Schedule to be announced in a few days

• Course message forum

• Read posts from other students before posting your question

• Read the spec – very often your answer will be in there