The project work

Background

The group work results/methods

The preliminary specification

Background (shortly):

 We have 4 different basic options:
• A project from a company students are working for (the subject area must be closely connected to the module, operating system internals, inter process communication of a multitasking system.....).
• A project based on the example kernel.
• A project specified below.
• Linux device driver project.

 

• Industry needs nowadays engineers who have good teamwork capabilities.
• It would be easier and more ”fear” for everybody to do all laboratory works ”personally”, unfortunately the easiest way is not always the best way.
• Data communication systems are the fastest developing are of industry in the whole world (work subject/topic/theme).

The group work results/methods

(Software project for ex. Sommerville/ Software Engineering):
 The work must start as soon as possible (to be able to sort out possible the problems). A student gets 4 gredit units from the project course. This means 160 hours of work and for a group of 4 students 640 working hours. You should not try to start the project during the last weekend an to try "work hard day and night".
• The whole work is scheduler to be ready 30.4.01. If the work is not ready the project will expire, however, you can submit a working but a little bit simplified program (effect on grading). Also, when problems arose, for example a member of a team is not doing his part or leaving, we can discuss how to solve the problem (simplified specification or something else).
• The nucleus of the work, without additional features is most important (start the implementation with the nucleus).
• Groups are from 1 to 4 persons (you must be a very good reason to work alone).
• A group has a leader.
• Each member has a clear documented area of responsibility but:
Design and technical meetings are important/ don’t only assign some task/student.
• Group (proceeding) meetings at least once a two weeks.
• Quality reviews.
• A group produces:

• Requirements specification document
• Architectural specification
• Project plan (resource allocation ”Pert- diagram”)
• Test specifications
• Object oriented design (OOD) or (UML)
• Coding (c++ or C- language, module headings, comments)
• Testing (module test + system test) , test results reported
• Proceeding reports
• Final documentation ( style as for an important customer)
• Students should be divided to groups so that all the best students do not work in the same group. Every group should be "heterogeneous" as to programming skills.
• The final grading is also based on the report of the group (the responsibility area of every member) and discussions about merits of the group members.

Requirements Specification

A simplified simulation of a data communication packet switch software

We simulate a packet network  in the UNIX environment. A packet switch is a UNIX process, which takes packets from simulated lines and routes packets to lines using addresses in the packet header and a routing table in the packet node. For testing purposes we have to have programs to send (initiate) packet data to lines and programs to get and display data from lines.
The network must be dynamically configurable:

• Routing tables are set using  command line arguments
• Connections to other nodes are set using command line arguments
• Host computers connected to a node are defined using command line arguments
  For example: we start a program to be run with the following command line information:
• You are a node computer named Node1
• The host computers HostH1 and HostH2 are connected to this node
• You are connected to nodes Node5, Node4 and
• Every packet from the host computer HostH1 or HostH2 destinied to the  host computer HostH6 are sent to the node Node4 to be re-routed (and so on) and packets from HostH1 or HostH2 to the host HostH3are sent to to Node5.

 
 
 


 
 
 
 
 

We have 4 variations of the project specification:

1. Simple basic system specified above.
2. Some of the hosts and nodes are running in different computers (Berkeley sockets used).
3. One of the above systems plus broadcasting of the routing tables implemented (must be reliable method to negotiate the updating; study literature).

Number of students/project on average:

• The option 1 (one student if acceptable reason- not full time student or something else).
• The options 2 and 3 three students.


The assessment depends also (in addition to the quality) on the project and the number of students, for example: If 4 students will take the option 2 (normally for 3), maximum  grades can't be as high as for 3 students. If 2 students take the option 2 it is a merit.

Some comments to the implementation:

The simplest method is using of named pipes (FIFO) or message passing IPC- method, also allowed to use shared memory for the communication. Do not use ordinary pipes for communication. Every node of the network is started as a separate process from a command script file.
No active looping waiting for some event is allowed (You must always use an operating system call for waiting). One very good system call for waiting an event is select(2). The ”select” call can be set to wait several communication channels at the same time. The call returns the channel which has an event to be delivered. The system must be tested:
•     Hosts send test files to others hosts. File contents are compared.
•     Tests must be organized so that we have heavy traffic load (not a single packet a time).