Description
• General Description
Please read the WHOLE assignment description before start implementing.
We all know how bad the university’s “Course Registration System” is, now you may have a chance to change it 🙂
In this assignment you will implement a “Course Registration System” server and client. The communication between the server and the client(s) will be performed using a binary communication protocol.
The implementation of the server is based on theThread-Per-Client (TPC) and Reactor servers taught in class.
You are required to implement the BGRS (Ben Gurion Registration System)
protocol, which emulates a simple course registration system.
The messages in this protocol are binary numbers, composed of an opcode (short number of two bytes) which indicates the command, and the data needed for this command (in various lengths).
In the following sections, we define the specifications of the commands supported by the BGRS protocol.
Unlike real course registration systems, the courses are specified in one file, according to a specific format (shown below). The data which the server and clients get during their running are saved in the RAM (in data structures, e.g., arrays, lists, etc…)
• Establishing a client/server connection
|
Upon connecting, a client must identify himself to the service. A new client will issue a Register command with the requested user name and password. A registered client can then login using the Login command. Once the command is sent, the server will acknowledge the validity of the username and password. Once a user is logged in successfully, she can submit other commands. The register and login commands are stated in the following section. Note that the register command will not perform automatic login (you will need to call login after it). |
|
1.2 Courses File The data about the courses (for the server use) are given by a text file which you will define beforehand. The file name MUST be Courses.txt, and it should be located in the main folder (the project folder). The file consists of lines, where |
|
every line refers to a specific course. The format of a single line will be as follows: courseNum|courseName|KdamCoursesList|numOfMaxStudents numOfMaxStudents: the maximum number of students allowed to register to this course(int >= 5) |
No spaces before and after the ‘|’ character – you don’t need to check that.
The course name doesn’t contain the ‘|’ character – you also don’t need to check that.
You can assume that the courses file is formatted well (means, all courses lines are written in the correct format), so no need to check that.
Example:
42|How to Train Your Dragon|[43,2,32,39]|25
1.3 Supported Commands
2 bytes Opcode
Opcode
1 2 3 4 5 6 7
8
9 10
Length defined by command …
Operation
Admin register (ADMINREG)
Student register (STUDENTREG)
Login request (LOGIN)
Logout request (LOGOUT)
Register to course (COURSEREG)
Check Kdam course (KDAMCHECK)
(Admin)Print course status (COURSESTAT)
(Admin)Print student status (STUDENTSTAT)
check if registered (ISREGISTERED) Unregister to course (UNREGISTER)
|
The BGRS protocol is composed of two types of commands, Server-to-Client and Client-to-Server. The commands begin with 2 bytes (short) to describe the opcode . The rest of the message will be defined specifically for each |
|
command as such: |
We supplied functions that encode \ decode between 2 bytes and short for both java and C++ in the assignment page.
The BGRS protocol supports 11 types of messages:
- 1)Client-to-Server messages
- 2)Server-to-Client messages
11
12 13
Check my current courses (MYCOURSES)
Acknowledgement (ACK) Error (ERR)
ADMINREG Messages:
Messages have the following format:
2 bytes Opcode
Parameters:
Command initiation:
string Username
1 byte 0
string Password
1 byte 0
Messages that appear only in a Client-to-Server communication.
An ADMINREG message is used to register an admin in the service. If the username is already registered in the server, an ERROR message is returned. If successful an ACK message will be sent in return. Both string parameters are a sequence of bytes in UTF-8 terminated by a zero byte (also known as the ‘\0’ char).
- Opcode: 1.
- Username: The username to register in the server.
- Password: The password for the current username (used to log in to
the server).
• This command is initiated by entering the following text in the client command line interface: ADMINREG <Username> <Password>
STUDENTREG Messages:
Messages have the following format:
2 bytes Opcode
string Username
1 byte 0
string Password
1 byte 0
Messages that appear only in a Client-to-Server communication.
A STUDENTREG message is used to register a student in the service. If the username is already registered in the server, an ERROR message is returned. If successful an ACK message will be sent in return. Both string parameters are a sequence of bytes in UTF-8 terminated by a zero byte (also known as the ‘\0’ char).
Parameters:
- Opcode: 2.
- Username: The username to register in the server.
- Password: The password for the current username (used to log in to
the server).
Command initiation:
• This command is initiated by entering the following text in the client command line interface: STUDENTREG <Username> <Password>
LOGIN Messages:
Messages have the following format:
2 bytes string 1 byte
Opcode Username 0
string 1 byte
Password 0
Messages that appear only in a Client-to-Server communication.
A LOGIN message is used to login a user into the server. If the user doesn’t exist or the password doesn’t match the one entered for the username, sends an ERROR message. An ERROR message should also appear if the current client has already successfully logged in.
Both string parameters are a sequence of bytes in UTF-8 terminated by a zero byte.
Parameters:
- Opcode: 3.
- Username: The username to log in the server.
- Password: The password for the current username (used to log in to
the server)
Command initiation:
|
• This command is initiated by entering the following text in the |
|
client command line interface: LOGIN <Username> <Password> |
LOGOUT Messages:
Messages have the following format:
2 bytes
Messages that appear only in a Client-to-Server communication. Informs the server on client disconnection. Client may terminate only after receiving an ACK message in replay. If no user is logged in, sends an ERROR message.
Parameters:
• Opcode: 4. Command initiation:
Opcode
• This command is initiated by entering the following text in the client command line interface: LOGOUT
• Once the ACK command is received in the client, it must terminate itself.
|
COURSEREG Messages: |
|
Messages have the following format: |
2 bytes 2 bytes
Opcode Course Number
Messages that appear only in a Client-to-Server communication. Inform the server about the course the student want to register to, if the registration done successfully, an ACK message will be sent back to the client, otherwise, (e.g. no such course is exist, no seats are available in this course, the student does not have all the Kdam courses, the student is not logged in) ERR message will be sent back. (Note: the admin can’t register to courses, in case the admin sends a COURSEREG message, and ERR message will be sent back to the client). Parameters
Opcode: 5
Course Number: the number of the course the student wants to register to.
Command initiation:
• This command is initiated by entering the following text in the client command line interface: COURSEREG <CourseNum>
KDAMCHECK Messages:
Messages have the following format:
2 bytes
Opcode
2 bytes
Course Number
Messages that appear only in a Client-to-Server communication.
KDAMCHECK this message checks what are the KDAM courses of the specified course.
If student registered to a course successfully, we consider him having this course as KDAM
Parameters:
• Opcode: 6.
• Course Number: the number of the course the user needs to know its KDAM courses
When the server gets the message it returns the list of the KDAM courses, in the SAME ORDER as in the courses file (if there are now KDAM courses it returns empty string).
Command initiation:
KDAMCHECK <CourseNumber>
2 bytes 2 bytes Opcode Course Number
• This command is initiated by entering the following texts in the client command line interface:
COURSESTAT Messages:
Messages have the following format:
(Admin Message)
|
Messages that appear only in a Client-to-Server communication. |
|
alphabetically |
Parameters:
• Opcode: 7
Course Number: the number of the course we want the state of.
Command initiation:
COURSESTAT <courseNum>
STUDENTSTAT Messages:
• This command is initiated by entering the following texts in the client command line interface:
(Admin Message)
Messages have the following format:
2 bytes Opcode
String Student Username
1 byte 0
Messages that appear only in a Client-to-Server
A STUDENTSTAT message is used to receive a status about a specific student.
the client should print the state of the course as followed:
Student: <studentUsername>
Courses: <listOfCoursesNumbersStudentRegisteredTo> //ordered in the same order as in the courses file Example:
Student: hhhaddock
Courses: [42] // if the student hasn’t registered to any course yet, simply print []
Parameters:
•
Opcode: 8.
Command initiation:
|
• This command is initiated by entering the following texts in the client command line interface: STUDENTSTAT |
|
<StudentUsername> |
ISREGISTERED Messages:
Messages have the following format:
2 bytes 2 bytes
Opcode Course Number
Parameters:
Command initiation:
2 bytes 2 bytes Opcode Course Number
Parameters:
Command initiation:
MYCOURSES Messages:
Messages have the following format:
2 bytes
Messages that appear only in a Client-to-Server communication.
An ISREGISTERED message is used to know if the student is registered to the specified course.
The server send back “REGISTERED” if the student is already registered to the course,
otherwise, it sends back “NOT REGISTERED”.
- Opcode: 9.
- Course Number: The number of the course the student wants to
check.
• This command is initiated by entering the following texts in the client command line interface: ISREGISTERED <courseNum>
UNREGISTER Messages:
Messages have the following format:
Messages that appear only in a Client-to-Server communication.
An UNREGISTER message is used to unregister to a specific course
The server sends back an ACK message if the registration process successfully done, otherwise, it sends back an ERR message.
- Opcode: 10.
- Course Number: The number of the course the student wants to
unregister to.
• This command is initiated by entering the following texts in the client command line interface: UNREGISTER <courseNum>
Opcode
Parameters:
• Opcode: 11. Command initiation:
Messages that appear only in a Client-to-Server communication.
A MYCOURSES message is used to know the courses the student has registered to.
The server sends back a list of the courses number(in the format:[<coursenum1>,<coursenum2>]) that the student has registered to (could be empty []).
• This command is initiated by entering the following texts in the client command line interface: MYCOURSES
•
2 bytes Opcode
2 bytes
Message Opcode
–
String to be printed at the client side (as bytes)
1 byte 0
ACK Messages:
Messages have the following format:
Messages that appear only in a Server-to-Client communication.
ACK Messages are used to acknowledge different Messages. Each ACK contains the message number for which the ack was sent. In the optional section there will be additional data for some of the Messages (if a message uses the optional section it will be specified under the message description).
All Messages that appear in a Client-to-Server communication require an ack/error message in response.
Parameters:
- Opcode: 12.
- Message Opcode: The message opcode the ACK was sent for.
- Optional: changes for each message.
Client screen output:
ACK <Message Opcode> <Optional>
Parameters:
• Any ACK message received in client should be written to the screen in the following manner:
• Printing of the optional part: split between optional parameters by space.
ERROR Messages:
Messages have the following format:
2 bytes 2 bytes Opcode Message Opcode
Messages that appear only in a Server-to-Client communication.
An ERROR message may be the acknowledgment of any other type of message. In case of error, an error message should be sent.
- Opcode: 13.
- Message Opcode: The message opcode the ERROR was sent for.
Error Notification:
• Any error message received in client should be written to screen:
- Implementation Details
- General Guidelines
ERROR
<Message Opcode>
In any case, if the message cannot be processed successfully, or the user is not
allowed to send this message (e.g. student sends an admin message), the server
returns an ERROR message.
|
• The server should be written in Java. The client should be written |
|
in C++ with BOOST. Both should be tested on Linux installed at CS computer labs or the provided VM.
|
• Server
You will have to implement a single protocol, supporting both the Thread-Per- Client and Reactor server patterns presented in class. Code seen in class for both servers is included in the assignment wiki page. You are also provided with a new class:
• Database – This is a singleton class that should be used in order to manage the Courses and Users. You must only use this class in order to do that. Notice that this class should be thread-safe.
•
• (UesxearmNpalme e-) n–ortetruerqnusirtehde)pSatsrsinwgorgdetoUf stehrePuaseswrnoarmd(eString
Left to you, are the following tasks:
|
1. Finish the Database class. |
|
2. Implement |
Leading questions:
Tip:
Testing run commands:
• Reactor server:
• Which classes and interfaces are part of the Server pattern and which are part of the Protocol implementation?
- When and how do I register a new user in the Database class.
- Which class(es) use the Database class, apart from the initialize?
• When do I call initialize to initiate the Database?
• You can test tasks 1 by fixing one of the examples in the impl folder in the supplied spl-net.zip to work with your implementations (easiest is the echo example)
mvn exec:java – Dexec.mainClass=”bgu.spl.net.impl.BGRSServer.ReactorMain” –
Dexec.args=”<port> <No of threads>”
• Thread per client server:
mvn exec:java – Dexec.mainClass=”bgu.spl.net.impl.BGRSServer.TPCMain” –
Dexec.args=”<port>”
The server directory should contain a pom.xml file and the src directory. Compilation will be done from the server folder using:
mvn compile
• Client
An echo client is provided, but its a single threaded client. While it is blocking on stdin (read from keyboard) it does not read messages from the socket. You
should improve the client so that it will run 2 threads. One should read from the keyboard while the other should read from socket. The client should receive the server’s IP and PORT as arguments. You may assume a network disconnection does not happen (like disconnecting the network cable). You may also assume legal input via keyboard.
The client should receive commands using the standard input. Commands are defined in section 1.2 under command initiation sub sections. You will need to translate from keyboard command to network messages and the other way around to fit the specifications.
Notice that the client should close itself upon reception of an ACK message in response to an outgoing LOGOUT command.
The Client directory should contain a src, include and bin subdirectories and a Makefile as shown in class. The output executable for the client is named BGRSclient and should reside in the bin folder after calling make.
Testing run commands: BGRSclient <ip> <port>
