Lab Project 1 (24 July - 4 August 2017)

Suggestions:
  • Start with the encode c program.
  • Use the example from the handout to make sure your code works correctly.
  • Implement decode, using almost exactly the same code as encode - just swap the table around at the end.
  • For more information about c programming, please check the online tutorial here (https://www.tutorialspoint.com/cprogramming/)
Your code should run like this:

circa: [Code] % cat test | encode "i came, i saw" | decode "i came, i saw"
key: HJKLNOPQRTUVICAMESWXYZBDFG - 26
key: OWNXQYZAMBCDPEFGHIRJKLSTUV - 26
ALICE, MEET YOU AT THE PARK, BOB

Note the effect of changing one character in the key

circa: [Code] % cat test | encode "i came, i saw" | decode "i came, i sag"
key: HJKLNOPQRTUVICAMESWXYZBDFG - 26
key: OJNKQLSTMUVWPXYZABRCDEFGHI - 26
TEBVX, MXXG LOH TG GAX PTRD, UOU


Lab Project 2 (6 August 2017)

About the test files (beware, you need to increase the size of the text array (at the top) to 200,000 char:
  • Alice.txt - plaintext
  • and...
  • cAliceby1.txt - enciphered by mono-alphabetic Caesar cypher.
  • used: > cat cAliceby1.txt | ./crack 1 > Aliceby1.out
  • Aliceby1.out - my output (stdout - not stderr)
  • and...
  • cAliceby2.txt - enciphered by poly-alphabetic Caesar cypher, using 2 keys.
  • used: > cat cAliceby2.txt | ./crack 2 > Aliceby2.out
  • Aliceby2.out - my output (stdout - not stderr)
What you will notice is that it is not all that obvious which is the decode with the right 'guess' in terms of numbers of keys - but once you identify some words, it becomes a lot clearer. We're relying on the human here as an integral part of the decyption. Remember, when you specify 2 keys to crack, this is a max, it will try 1 and 2. An argument of 3 would try 1,2, and 3.

Lab 3: Flooding (due 17th August, 23:59)

The purpose of this lab is to get you familiar with the cnet simulator - in the next lab (lab 4) you will implement part of a routing protocol. The Cnet simulator enables development of and experimentation with a variety of data-link layer, network layer, and transport layer networking protocols in networks consisting of any combination of wide-area-networking (WAN), local-area-networking (LAN), or wireless-local-area-networking (WLAN) links. In our labs we will only be looking at the routing layer.

The full documentation of cnet can be found here: http://www.csse.uwa.edu.au/cnet/

There will be no implementation in this part, instead we will provide you with a working implementation that uses flooding. As will be mentioned in class, this is a horrible way to route data within a network, as it does not scale, due to the exponential increase data and therefore in link congestion. In the experimental part of this lab you will gather some results that demonstrate in a small way the problem of poor scalability.

First things first. Getting cnet running (during Lab).

  1. Grab the following distribution flooding-dist.tar.
  2. tar -xvf flooding-dist.tar
  3. Now execute the code (it will automatically compile etc.)

    cnet WORLD

  4. Click on machines and links, and explore the data presented. Note the ends of the links are different - see images below.
  5. Make sure you choose "run" from the menu bar and you can toggle the speed.
Exploring the links: links.png

Exploring a Host: hosts.png

Flooding Implementations

There are three cnet implementations of Network Layer flooding. Each algorithm is of increasing complexity and efficiency. There are details of each algorithm in the comments at the top of each source protocol file. You might want to consider these when thinking about the results you gather.

Experiment

What I want to you to consider is how each of the implementations scales. To do this you will need to create a topology file for various size networks. The connections and hosts are described by such a topology file. In the distribution you have been provided WORLD.MAP and NEWZEALAND.MAP- you will need to (subtractively) edit these to create test topologies of different sizes:

  1. Wellington & Auckland (North Island)
  2. Wellington, Auckland, Christchurch and Dunedin (NZ) - this is provided for you.
  3. NZ + Australia
  4. The world
  5. You may need 'make clean'

Todo:

  1. Look at the 2 Readme files.
  2. Run each of the 3 implementations of flooding over each of the above topologies.
  3. To do this, you should make versions of "getfloodstats" that use your new topologies (getfloodstats currently uses the supplied NEWZEALAND.MAP
  4. Graph the results - 4 graphs (plot each of the 3 flooding implementations per topology).
  5. Double the hop limit on NZ + Australia and the WORLD. What happens?
  6. Plot the 2 graphs showing both 4 and 8 hop results (just used flooding3).

Submission (17th August 23:59)

For part a, you need to submit (electronically):

  1. A lab report, presenting your graphed results and an analysis of the performance of each flooding algorithm. Include an explanation of any differences in the results that are due to the difference in the algorithms. This report should be no longer than 4 pages (incl your 6 graphs).
  2. Your North Island and NZ+Australia topolgies.
  3. Please note, there is no demonstration.

Lab 4: Routing (due 15th September, 23:59)

The description for this lab can be downloaded from here: Lab 4.pdf.

A lab tutorial will be held on Thursday 24 August 2017 at 12:00pm in Maclaurin LT102.

Lab 5: Building a TCP client (demo in lab in between 11 September and 29 September)

The description for this lab can be downloaded from here: tcp-ip-lab-5.pdf

The C skeleton for building your TCP client program can be found here: tcpclient-skel.c

Lab 6: Building a TCP server (submission due on Sunday 1 October, 23:59)

The description for this lab can be downloaded from here: lab-project-6-2017.pdf

The C skeleton for building your TCP server program can be downloaded from here: tcpserver-skel.c

Lab 7: Create an Android mobile application (demo in lab in between 2 October and 19 October, submission due on Friday 20 October)

This lab exercise helps you learn Android application development and build your first Android application. We will particularly develop an Android application to retrieve and display daily movie images from the RSS feed: http://movieweb.com/rss/all-news/.

Lab 8: Develop a Web Service application (submission due on Sunday 22 October at 23;59)

This lab project helps you get familiar with the web service technology and develop your own web service provider and consumer. In lab demo is recommended but not compulsory for this lab.
  • Description of this lab project can be found here: NWEN 243 lab project - web service.pdf
    • No lab report is required for this lab project.
    • You must submit your Web Service project online in the form of a zip file. Please zip your entire eclipse project to make it easy for tutors to check your submitted code.
  • You must use Tomcat server v6.0 as your web service run time. Please download this software system from here (apache-tomcat-6.0.41.zip) and unzip it to an empty directory in your computer.
  • You must use some third-party library files to support your web service implementation. They can be downloaded from here: lib.zip
  • You are required to answer 5 topic questions given in here: topic-questions-lab8.pdf
    • Please provide your answer to these questions in a separate PDF document and submit your answers together with your project code.