Project Outline

(This text contains extracts from the background sectionof the requirements specification.)

Project Brief

          Heriot-Wattwas approached by the Computing Studies Department of Kelso High School in the Scottish Borders, with a brief to produce several pieces of coursewarefor the computing studies course at the school. The piece of coursewarethat will be looked at in the project is an Inter-PC Network Simulator.This software was originally written for the BBC Micro and produced forthe school by St. Andrew’s College in Glasgow. The purpose of the softwarewas to provide the user with an insight into how two computers may communicatewith each other. The user acts as the control system of the computer, workingout which procedures to call and in which order, so as to achieve successfuldata transfer. To focus on achieving this goal the ‘network’ and protocolswere kept purposely simple. Even though the software was produced for theschool, numerous bugs and the steady decline of the BBC computers meantthat the software was never effectively used. Therefore, the brief forthis project was to replace the old BBC software with Windows™ based softwarefor the PC’s which now form the backbone of the schools IT equipment.


The School & it’s Computing Facilities

Kelso High School is located in the Borders region ofScotland. Like many high schools, it’s IT facilities have been built upover a number of years and Kelso now have a significant IT department.8 years ago, the school had a small local area network linking 20 BBC microsand 10 RM Nimbus 186 PC’s. Since then, the usual progressions through 286’sand 386’s have been seen as well as an upgrade from the old network systemto an Ethernet™ network. The network now covers close to the entire school,linking 4 computer labs containing a mixture of 386, 486 and Pentium™ PC’s.In addition, nearly every department has a selection of machines linkedinto the network. The network is controlled by 2 dedicated Pentium servers,linked by a thick Ethernet backbone while the rest of the schools machinesare connected into a thin Ethernet. This ensures that networks play animportant role in the IT function of the school.


Networks and the Curriculum

As can be seen from the previous material, networks areplaying a more and more significant role in how we interact with computersand, as a result, computer communications is a very important aspect ofthe teaching of computing. Pupils will spend over 40 hours of the courseexamining networks, how they operate and the role they play in an IT environment.This section of the course is broken down into four elements:

Analysing common network application programs and howthey operate: Looking at applications such as FTP and e-mail, examiningtheir usage in detail as well as looking at international standards involved.
The design of network architecture: Looking at the ideaof a layered architecture and examining the layers of the ISO OSI modeland how they interact.
Protocols, their functional components and their operation:Looking at the use of protocols and their components. (e.g. encoding, flowand error control.)
Matching network technical specifications to functionalrequirements: Applying networking principles to real situations and examiningits impact.


Required Learning Outcomes of Software

The software is used as part of the protocols sectionof the course. In addition to the learning outcomes set out in the generalcurriculum for this section, there are specific learning outcomes establishedfor the use of this software. These will help to mould the requirementsfor the project. Through use of the software, the user (pupil) should understandthat:

Data transfer across a network is structured and controlledto ensure successful communication.
This structure and control is created by protocols whichare simply standard ways of carrying out the various tasks involved.
In this software, the protocol relates to:
Encoding information - The translation of messages intostandard form packets.
Flow control - The exchange of signals between the transmitterand the receiver before transferring data.
Error control - The inclusion in the packet of and errorchecking algorithm.
When the receiver receives a packet it carries out thesame error check as the transmitter and transmits an acknowledgement asappropriate.


The Protocol

The purpose of this simulation is to get the pupils actingas the control system in network stations, working out which proceduresto use and in which order to allow for successful data transfer. In orderto focus on this, the network and protocol has been kept intentionallysimple. The protocol is a simple ‘stop and wait’ protocol using CyclicRedundancy Checks for the error checking. The protocol can be broken downas follows:
A Request to Send (RTS) signal is sent to the destinationmachine.
A Clear to Send (CTS) signal is sent back to the sourcemachine if it is free to send. The destination machine cannot then sendan RTS.
The data packet is built on the source machine, incorporating:
The source address
The destination address
The message
The Cyclic Redundancy Check (CRC)
The data packet is sent to the destination machine.
When the packet arrives at the destination, an errorcheck is carried out.
If the packet is error free, an acknowledgement (ACK)is sent to the source.
If the packet has errors, a negative acknowledgement(NACK) is sent to the source.


The Original Software

The original software followed a simple format: The program was run simultaneously on two BBC Micros, interconnected by a serial cableand each machine was allocated a 4 bit binary address. A simple text basedmenu system presented the user with a choice of actions to take. Thesewere presented in no particular order in the menu so as to encourage theuser to decide on the order of the protocol. The user then had to selectthe appropriate actions to ensure a successful transmission. On the othermachine, the second user had to respond to the actions being performed.An inappropriate step would produce an error message, but not an explanationof how to correct it. This ensured that the users weren’t just followinga series of instructions on the screen but actually having to think outthe steps for themselves. To simulate a bad transmission, the softwarewould produce random errors in the transmission and, again, users wouldhave to work out how to deal with it.

The choices of actions were as follows:

Send Request To Send (RTS)
Error Check
Send Clear To Send (CTS)
Send Packet
Build Packet - This then requested a source and destination address (binary), a message and the result of the Cyclic Redundancy Checkon the packet. Users are warned if they attempt to send an incomplete packet.
Send Negative Acknowledgement (NACK)
Send Acknowledgement (ACK)

 Back to Project Page

Stephen Denning
Last Updated: 4th February 1998