|
|
Practical project 2024
(due 11:59pm Fri 17th May - end of week 11)
See also:
Getting Started
and
Clarifications (28/4)
The goal of this project is to develop a server application
supporting queries about bus and train routes,
such as those in the Transperth transport network.
By successfully completing the project,
you will have a greater understanding of
the standard TCP and UDP protocols running over IP,
communication between web-browsers and application programs using HTTP and HTML,
and will have developed a simple text-based protocol to
make and reply to queries for distributed information.
A transport network can be considered as a connected graph -
the bus and train stations are nodes in the graph,
and the bus and train routes are links joining the stations.
Multiple bus and train trips commence at different times
throughout the day,
and pairs of stations are connected by multiple bus and train routes.
In this project:
-
each bus or train station will be represented by an executing instance
of a
station server
(software).
Each station server will be a distinct operating system process
(not a thread within a single process).
Each station server runs the same software,
but manages its own data and network connections.
-
a standard web-browser will provide the human-facing interface to each server,
so this project doesn't require the development of client software.
However, a small amount of basic HTML code will need to be developed to
support the interface through the browser.
-
a very simple webpage (rendered via a web-browser)
will accept queries to find the sequence of buses and trains (a journey)
to travel from one bus or train station to another.
The web-browser will transmit the query to the instance of the
station server (software) representing the
source station
(presumably one close to the user's home),
asking it how to travel to a
destination station.
-
each bus or train station server only maintains the timetable information
of buses and trains leaving that station,
including the destination of each,
and the (multiple) times throughout each day that each bus leaves the
station and arrives at the destination.
-
if the source and destination stations
are directly connected (via a single bus or train trip),
then the source station server will be able to immediately
respond to the query because it has all necessary information.
-
if, however,
the source and destination stations are not directly connected,
the passenger will have to travel via two or more buses or trains,
transferring at intermediate station(s).
Because each station server only knows about buses and trains leaving that station,
it will need to ask other stations' servers for information about the next
segment (or hop) of the whole journey.
-
the result (the answer) returned from the source station back to the
web-browser will indicate
the number,
and departure time of the
next bus or train leaving the source station
that enables the passenger to reach the required destination station,
and the expected final arrival time at the destination.
Ideally,
the returned result will be the fastest journey -
even if it leaves later or includes more segments (hops) than other journeys
(but firstly, just report any any valid journey!)
Networking details
- each station server
will run as a separate operating system process (not a thread in a single process).
- station servers will execute on one or more computers.
Command-line arguments specify the host names and networking ports that each
should use.
A typical invocation of two station server processes is:
shell> ./station-server
Usage: ./station-server station-name browser-port query-port neighbour1 [neighbour2 ...]
shell> ./station-server Warwick-Stn 2401 2408 host2:2560 host3:2566 .... &
shell> ./station-server.py Greenwood-Stn 2402 2560 host4:2567 host1:2408 .... &
which indicates that the first process (a compiled C program)
will manage the data of the station named "Warwick-Stn",
will receive queries from web-browsers using TCP/IP port 2401,
will receive datagrams from other stations using UDP/IP port 2408,
and that "Warwick-Stn" is 'physically adjacent' to 2 other stations,
executing on host2 and host3,
which are receiving station-to-station datagrams on UDP/IP ports 2560 and 2566, respectively.
The second server process (a Python script)
will similarly manage the data of the station named "Greenwood-Stn",
and is 'physically adjacent' to "Warwick-Stn".
Notice, also,
that both processes have been 'started in the background',
because neither needs to remain connected to the invoking keyboard.
- each station server will accept queries about its timetable
data from a standard web-browser (a passenger making a query from their mobile phone).
The query and reply will be transmitted using the
(minimum amount necessary of the) HTTP protocol,
the Hypertext Markup Language (HTML),
carried over a bidirectional TCP/IP connection.
After the exchange of each query and its response
the station server must close the connection.
- station servers will communicate with adjacent stations,
if necessary,
using UDP/IP datagrams.
- no station server should ever contain all knowledge about
the whole network,
timetabling data,
or network connections.
Each station's timetabling data,
recorded in one textfile for each station,
may change at any time
(for example, if a bus breaks down, its next trip will be cancelled).
Every query arriving at a station server (via a UDP/IP datagram)
should be answered using the current up-to-date timetable information for that station.
Constraints
The constraints of the project require that:
- your project must be developed in two
programming languages Python and (C or C++) -
note, not C and C++.
You must develop two implementations of the station server,
in two different programming languages.
The two implementations must perform identically - as a client of these servers
you should not be able to tell (or care) what programming language is being used.
- you should employ the core networking functions
(methods, modules, libraries,...)
of your chosen programming languages and not employ specific 3rd-party
frameworks or resources to complete large parts of the project.
Specifically,
you must not
use Python's http.server module (even though it is a standard module),
or use C++'s Boost library.
The learning in this project comes from developing an understanding of
how an operating system's system calls,
and programming languages' standard libraries,
may be used to address these types of problems.
There is far less learning (or a different type of learning)
required in just combining existing libraries and modules
to solve this problem.
If in doubt, please ask.
- your project will be marked on either Linux or Apple macOS.
Your project does not have to work on both operating systems
(though that should not be difficult).
Clearly indicate in your submission which operating system you used.
Project inputs
See the
Getting Started
page for an example of a simple 4-station network.
While your servers will need to read in and parse the contents of the timetable files,
you can assume that all their contents are correct
(time-formats are correct, departure times precede arrival times,
destination station names exist, etc).
The Getting Started page provides a small number of helpful
shellscripts to generate and execute your transport networks
(you do not have to use these shellscripts if you wish to manage these steps yourself).
One shellscript extracts necessary information from downloaded
Transperth GTFS datafiles,
but you should not attempt to use such a large dataset until
you have tested your project on a much smaller transport network.
You can define your own simple transport networks for testing your servers;
just invent some station names,
and timetable information for buses connecting the servers.
You do not need to use the full set of Transperth GTFS files to start the project.
Important dates and project submission
-
The project contributes 40% of your mark in CITS3002 this semester
-
The project is to be completed by teams of between
one and four students.
You may discuss general ideas with other students,
but you may not share code from your developed solution.
You may use material found in books or tutorials
(either physical or online)
but must cite the sources of such material.
-
The project's deadline is 11:59pm Friday 17th May (end of week 11).
By this deadline submit all source code files and
(optionally, any new) scripts that you wish to be assessed.
Do not submit any of the original Transperth datafiles or station timetable files.
Submit your work via
cssubmit.
Ensure that each submitted file contains, as a comment,
and the names and student numbers of each team member.
Project demonstration
Your team must also arrange a demonstration of your software,
for up to 30 minutes, in week 12 (or possibly week 13).
The role of the demonstration is for you to demonstrate how much of the
project's goals you have met, and to answer questions to demonstrate your
understanding. It is not essential for all team members to be at your
demonstration, but ensure that those attending will be able to represent the
team.
A booking sheet will be provided closer to the deadline.
During the demonstration, your team should:
- briefly describe design decisions and assumptions
that you have made in your project. You must clearly
explain how it works,
identify what is being protected by your system,
how that protection is provided,
and identify any known weaknesses with your approach or its implementation.
- re-compile your programs,
and initialize and invoke the two server programs.
Describe the contents of necessary directories and files.
- demonstrate, through a small number of examples,
how someone may use your software system.
- do not prepare a PowerPoint-style presentation.
Marking rubric (/40 marks)
- 5 marks
Implementation of station-server processes in two programming languages,
employing (specifically) the standard Berkeley socket networking features
provided by each language, with no reliance on a shared file-system or other
inter-process communication mechanisms.
- 5 marks
Ability to receive a new TCP connection from a client (such as a
web-browser, or curl), receiving a request written in simple HTTP, and
replying to the same client using simple HTTP and HTML.
- 5 marks
Ability to establish a UDP communication endpoint, used to exchange
datagrams with neighbouring stations, and to communicate to (only) the UDP
ports of neighbouring stations.
- 5 marks
Ability to read a station's timetable file, storing it in a suitable
data-structure, which is accessed for each query; ability to detect that a
timetable file has changed, to delete/dispose of the previous information,
and move to using the new information.
- 5 marks
Design and implementation of a simple programming language independent
protocol to exchange queries, responses, and (possibly) control information
between stations.
- 5 marks
Ability to find a valid (but not necessarily optimal) route between origin
and destination stations, for varying sized transport-networks of 2, 3, 5,
10, and 20 stations (including transport-networks involving cycles), with no
station attempting to collate information about the whole transport-network;
ability to support multiple, concurrent queries from different clients.
Ability to detect and report when a valid route does not exist.
- 10 marks
Self and peer assessment using Spark+.
(details to follow).
Clarifications
Please post requests for clarification about any aspect of the project to
help3002
so that all students may remain equally informed.
Clarifications will be also added to the
project clarifications webpage.
Good luck,
Chris McDonald
April 2024.
|
