This page lists completed projects.
Price based Internet gateway
Many schemes have been proposed for price-based management of network traffic, where price is used as a signal to the user (or rather the user's application software) regarding the current load on network resources. This ideally allows the user application to adapt to network conditions in a way that optimises user satisfaction. In this project, a group of host machines will be connected to the Internet via a gateway, and all requests for remote server connection will be submitted via a pre-processor at the gateway. The gateway pre-processor and a special client on the host will negotiate regarding permission to connect. If the host agree to the current gateway conditions then the connection will be made to the remote server. The client software on the user's host machine is to provide an interface that allows the user to specify parameters that reflect the user's connection policy. The client then uses these parameters to negotiate each connection on behalf of the user.
Server failure detection and response
Assume you have a farm of N machines networked together on a common IP network (e.g. N < 20 and the machines are FreeBSD servers). Develop a distributed application that monitors the N machines and sends a pager or SMS message to one or more nominated phone numbers when a machine dies or is disconnected from the network. The monitoring mechanism must be self-contained within the set of N machines (no extra machine is available to run the monitoring program). The monitoring function must be robust against any machine failing. Each time a machine fails, the application adapts and continues operation across the remaining (N-1) machines. If a failed machine restarts, the application adapts again to resume monitoring the newly restarted machine.
Graceful shutdown of UPS-protected unix server farm
Assume a farm of N (N <=10) FreeBSD machines, and a single UPS that can be remotely monitored by one of the machines. All machines are powered through the UPS, but to save money we purchased a UPS that is only capable of supporting all N machines for five (5) minutes, or one primary machine for one (1) hour. Each machine is connected to a small, common IP network, also powered by the UPS. Develop a solution where the nominated primary machine monitors the UPS (e.g. over a dedicated RS232 link), and automatically initiates graceful shutdowns of the other (N-1) machines if mains power is lost. The solution should be configurable in terms of which machines make up the group, and allow for a hierarchy of shutdowns (e.g. some set of machines shutdown if power is gone for 2 minutes, another set of machines is shut down only if power outage lasts for 10 minutes, etc...)
Mapping online game player demographics
Under our GENIUS project we have been running some QuakeIII and Half-Life servers. Previous work with QuakeIII Arena
has established that play of online interactive games such as QuakeIII
and Half-Life tend to be cyclical over 24 hour periods, and dominated by
players within 170ms of the game server's location on the Internet.
Using regular Unix (FreeBSD) tools that we will supply, design and
implement a software package that can track the traffic in/out of a game
server's network link (e.g. sitting next to the server on a shared
Ethernet hub) and (in real-time) trace the IP paths to each client
(player). Your software should use techniques such as 'traceroute' or
inbound TTL measurements to infer the number of IP 'hops' each player is
from the server. Develop and document insights into the possible
relationships between 'hop count', typical latency between player and
server, and the frequency with which a player returns to a server. (You
might base this tool on pkthisto or something similar.)
for project outcomes.
The business of free software licenses
The term 'free software' has many connotations and some specific legal implications depending on the license under which software is made 'free'. Compare the GNU Public License (GPL, under which Linux is released) with the "BSD" unix license (under which e.g. FreeBSD and some other free unix implementations are released). Explain the implications of each license for commercialization of derivative works. Assume you start an undergrad or postgrad research project that grows into a viable spin-out company, and yet at the beginning you started by building on existing 'free' software components. What are the implications for your new company's business model if you initially chose GPL'd software vs BSD (or vice-versa) ?
IPv4 address space utilisation
.Almost all of the IPv4 addresses have been allocated, which will soon impede
the operation of anybody wanting a new internet connection. However, many of the
allocated addresses are not in use, because addresses have been allocated in a
way to simplify network management rather than maximise utilisation. This
project will measure the use of addresses within regions of the IP address space
to identify clusters of unused addresses.
Automatic rate limiting of online game cheats
Assume you are hosting an online game server (e.g. Quake3, Half-Life/CounterStrike) on a FreeBSD machine. Typically when a server operator decides a particular player is cheating, the player's IP address is "banned" and the client can no longer connect. The banned player quickly becomes aware of this and might try to work around the ban. For this project you must develop and implement an alternative solution - instead of outright banning of a cheater, use the dummynet driver in the FreeBSD kernel to add artificial latency (lag) and packet loss to the traffic going to and from the cheater's IP address. Other players should remain unaffected, and the cheater will have the frustrating experience of feeling as though their internet connection has suddenly become really bad. (FreeBSD is available free in the CAIA lab, and regular Linux game server binaries typically run as-is under FreeBSD.) Your project should implement a user-space frontend so that a game server operator can issue commands like "/lag <ipaddr>" to introduce penalty lag on a particular player.
Performance of Skype over WLAN
Work we have carried out indicates that the number of constant bit rate VoIP
calls that can be supported across a WLAN is limited by factors other than
bandwidth. In this project we will investigate whether similar constraints occur
for Skype over a WLAN. The project will be an experimental one where the
performance of Skype from a number of clients to a single access point will be
Latency and jitter sensitivity in First Person Shooter (FPS) games
For businesses planning on supporting fast-paced multiplayer games over the Internet the pool of potential customers depends on how tolerant players are to latency. Previous work with QuakeIII Arena suggests that players prefer servers less than 180-200ms away - i.e. paying customers will primarily come from the population within 180ms radius of any given server. This analysis was done using fairly crude estimates of 'ping' times between server and players (tens of samples per minute, using the server's uncalibrated timers). Develop a method for accurately sampling and estimating latency between client and server, build tools capable of monitoring at least two types of FPS (such as Half Life, CounterStrike, etc) , run public servers for a few months, then re-evaluate the validity of the "180ms radius" result. Comment on the possible impact of jitter, hop count, and game type on your results.
The war against Internet spam
The Internet is being flooded with unsolicited spam emails. It seems that until now there has not been an effective spam-stopping technique. This project aims to review anti-Spam state of the art methods. It will study existing/ proposed anti-spam mechanisms, and compare and evaluate their effectiveness. Its scope may be extended to a study of spam email traffic characterisation and an investigation of a spam email detection technique, that is capable of detecting spam traffic solely from the dynamic characteristics the traffic imposes on the network.
A study of hidden Internet traffic
There are various reasons for Internet application developers and users to hide their traffic. The common approach used is traffic encryption e.g. encrypted VoIP and encrypted P2P traffic. This makes it harder for network operators to identify these types of traffic using traditional traffic classification techniques such as TCP/UDP port based or payload based protocol reconstruction. The aim of this project is to study the basic packet/flow traffic patterns (e.g. packet length and inter-packet arrival time distributions) of these Internet applications. Its scope can be extended to develop a method for identifying such traffic solely from the dynamic traffic characteristics exhibit at the network layer.
See http://caia.swin.edu.au/urp/dstc, http://caia.swin.edu.au/sitcrc/angel
VoIP traffic measurement and other traffic interactions
VoIP is an important application in the current and future wireless network. This project involves measuring voice capacity supporting by the IEEE 802.11 protocol in a wireless LAN network. Detail characteristics (such as collision probability, delay and packet loss rate), as well as interaction between voice and other traffic over the wireless channel will also be studied.
IP-based telephony systems have many features that are not economically feasible in the traditional voice communication networks (PSTN). However, this sophistication brings additional vulnerabilities in term of security that must be addressed. This project will look at security issues (such as denied service attacks, authentication, spam, etc.) and suggest possible solutions for security problems in voice communication over wireless LAN networks.
Packet loss and bit error characteristics and delay variation over 802.11b wireless links
Wireless links in 802.11b WLAN are prone to significant bit errors and thus packet losses due to channel noise and interference, and packet collision. To deal with these problems, special techniques such as Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) are commonly used. These techniques change the bit error pattern at the link layer and the packet loss pattern at the transport layer, and introduce delay variation over wireless links. In this project, we would like to reveal how the packet loss pattern observed by upper layer protocols (such as TCP) is related to the bit error pattern at the link layer and discover the correlation between packet losses and delay variation over 802.11b wireless links.