CITS3002 Computer Networks

Practical project 2024

(due 11:59pm Fri 17th May - end of week 11)

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 - see the project clarifications webpage (5th May).
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  hostname2:2560  hostname3:2566 .... &

shell> ./station-server.py Greenwood-Stn  2402  2560  hostname4:2567  hostname1: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 describe your design choices, explain how your project works, 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)

Common marks for all team members - 30 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.

Updated An individual component - 10 marks:

A piece of reflective writing, at most one A4 page long (min 11 point font), reflecting on what you have learnt in this project. Your piece should comment on:
- how significant, and how successful, was your initial design process?
- what did you learn most from the project?
- what was the most difficult part of the project, and how did you address the problems?
- what knowledge or aspects from the project might you re-use in the next couple of years?
Submit a single file, either an MS-Word document (named reflection.docx) or a PDF file (named reflection.pdf), to cssubmit. Do not submit the file as part of an archive - just submit the correctly named file. Every student should submit their own file to their own cssubmit account (even if your account is the one receiving the whole project team's submission).
The UWA StudySmarter service has a succinct guide on reflective writing.

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.