The first component is a lab project, associated with labs 1 through 4 below.

The second component is a set of three lab investigation exercises associated with labs 5 through 7 below.

The deadline for both components is 5pm November 16th.

The first four labs, Sept. 10-Oct. 1 (there is no lab the first week of classes), are used to apply the networking concepts discussed in lectures to a practical lab project.

Lab network sessions: - Lab 1 sending/receiving - Lab 2 nonblocking receives and IO - Lab 3 threads/semaphores - Lab 4 select

The three labs from Oct. 15 - 29th will be used as investigative sessions, with a specific exercise to complete. The three exercises can be submitted to satisfy the lab component of the course, worth 25% of your course mark (due 5pm November 16th).

Investigative sessions: - Lab 5: distributed computation with Erlang - Lab 6: Erlang part II - Lab 7: Skype investigation

The labs for November 5th-26th will be set aside as working sessions for your lab work and/or your research project and presentation.

The labs in the final week (Dec. 3) will be used for project presentations.

Lab project
Either the lab project or the set of three lab investigations can be completed and submitted for your lab mark (20%).

Big Brother Team Tracker (BBTT)

As discussed in lectures, BBTT is a client-server system used to keep all members of a project team informed on the current location and activity of all other team members. It also automates the logging of what team members have been working on, when, and where.

Specifications may be refined here over the next week or two, and we will work on the design and key technical aspects in both the lectures and labs over the semester.

Implementation language: the project must be implemented on otter, and may be completed in either C++ (following the examples of labs 1-4) or in Erlang (following the examples of lab 6).

Due date: Friday November 16th at 5p.m.

Submission requirements:
Tar and gzip all the source code files, a readme file, and an appropriate Makefile into a single archive, and email it as an attachment to wesselsd@csci.viu.ca by the due date.

Language/platform constraints:
I will compile your client and server on otter using the Makefile you provide, and will test them on otter and the pups.

Product specifications:

General

• I'll refer to each person (team member) running a client as the user, and the person running the server as the admin.
• All communication between client(s) and server must be done using UDP.
• All recv/recvfrom operations should be non-blocking.
• Checks for keyboard commands (on both client and server) should be non-blocking.
• Neither the client nor the server should consume excessive cpu.

  The server

• The server should read or load a list of valid user names and passwords or logon keys.
• The server should be configured to listen on a range of ports.
• Once set up and listening, the server should periodically perform (nonblocking) checks for new keyboard commands or incoming messages, and process any commands or messages received.

  The supported (admin) keyboard commands should include:

  • H - to get help (display these commands)
  • D - display the current status of each user (name, location, time location was last updated, task, activity, time task or activity was last updated)
  • S - to shutdown the server after after broadcasting a shutdown message to the active users

  Each incoming message must include the username and password or key, which the server must validate against the list it loaded. Similarly, messages sent by the server should include a validation key to indicate the message really is coming from the server.

  The incoming message types (from the users) will either be status updates or shutdown messages. Any changes to a user's status (location, task, or activity) should be logged by the server and passed along to the other users.

  Note that clients and the server will treat the effective time for different events as the time at which they receive the message.

  The client

• The client obviously needs to be able to listen on a port, and to contact the server through a hostname or ip address.
• Once set up and listening, the client should periodically perform (nonblocking) checks for new keyboard commands or incoming messages, and process any commands or messages received.

  The supported (user) keyboard commands should include:

  • H - to get help (display these commands)
  • L - to change the user's current location
  • T - to change the user's current task
  • A - to change the user's current activity type
  • S - to shutdown the client after notifying the server

  Each outgoing message must include the username and password or key. Incoming messages from the server should similarly have an identification key which the client should check.

  The incoming message types (from the server) can be either shutdown notification from the server or a status update about a user. Any changes in status (location, task, or activity) should be updated on the client display.

• The client display should show the current status of all users (name, location and time that was last updated, task/activity and time that was last updated)