Transcript Presentation6

COMP1321
Digital Infrastructures
Richard Henson
November 2015
Week 6: Peripherals, Storage &
Device Communication

Objectives:
explain the difference in communication
involving peripheral and intelligent devices
produce a simple algorithm describing pointpoint communication between intelligent
devices
What is a “Peripheral”
anyway?
Digital…
 Generally not “intelligent”
 Controlled from the CPU, via
connection through motherboard
 CPU needs unique instructions for
each peripheral…

system software known a “driver”
Control of Peripherals

Input (e.g. keyboard):
 communication between
motherboard and peripheral to
establish
» electrical connection
» logical connection
 communication channel opened…
»
»
»
»
operating system call (e.g. INT 21)
data received into RAM…
flow rate & processing controlled by CPU
data passed on the requesting
application
CPU
Motherboard
ASCII
code
keyboard
Control of Peripherals

Output (e.g. screen):
 communication between
motherboard and peripheral to
establish
» electrical connection
» logical connection
CPU
Motherboard
 communication channel opened…
» data sent into RAM…
» operating system call (e.g. INT 21)
» flow rate & processing controlled via
CPU
» data passed from RAM to remote
peripheral
screen
Intelligent/Dumb Devices

Intelligent
 can process data independently
communication channel with CPU more
sophisticated
control software at each end of the
communication

Dumb
 controlled from CPU
dependent on driver software installed
on the computer…
Principle of “Handshaking”

First stage of communication:
makes sure devices in electrical & logical
contact
if so… establishes an agreed common set
of rules (protocol) for sending and receiving
data
Why “handshaking”?

Replicates what humans do…
equivalent of two multi-lingual people
walking up to one another, greeting each
other, and deciding which language they
will use to communicate:
» English, French, Chinese?
» Smoke Signals, Semaphores, Morse Code?
Establishing a point-point
Communications Channel
$%^&£(?
eh?

For any two computers to
communicate digitally, they need
to “understand” each other’s
signals
Establishing a point-point
Communications Channel
$%^&£(?
eh?

Need a common “language”:
 i.e. a programmed set of rules and
procedures

Incorporated into software
 known as a “communications “protocol”
Establishing a point-point
Communications Channel
$%^&£(?
eh?

Each computer needs a copy of the
protocol rules:
 to send valid data
 to understand what the other computer is
sending
What is needed for a
Communications Protocol?

All the instructions for the CPU to organize
the sending/receiving of data…
 and ways to manage that data even when in
electronic format (i.e. 1= higher voltage, 0=
lower voltage)

At communication endpoints…
 synchronizing speed of sending/receiving
 error checking
 data encryption/compression & vice versa
Essentials for a
Communications Protocol


Agree a standard set of codes
First standard… ASCII, early 1960s
 set of control codes built into ASCII characters
Instructions, ASCII characters
and control codes
Rules and procedures for effective and
reliable communication between
devices converted into a language the
CPU can understand…
The ASCII control codes then need to be
incorporated into code written in that
language
code can be shared between the sender and
receiver
Point-Point Protocol
Protocol for
Comms mgt
Device
A
Protocol for
Comms mgt
Electrical signals
conversions
Device
B
conversions
Development of
Communication Protocols

Problem…
 Different manufacturers have historically
produced their own unique protocols,
 serve their own specific purposes
 some common ground…
» mostly used ASCII for control codes
» IBM used a system called EBCDIC (!)

Gradually, attempts at universal protocols
started to emerge…
 e.g. the people creating the Internet produced
TCP/IP in 1972
A simple point-to-point
communications protocol

Basis of a very simple algorithm that could be
translated into a program for managing
communications between individual devices
 ASCII control codes (0-31) for communications
between devices
 ASCII character codes (32-127) to carry data



Half duplex transmission
Data sent in “blocks” or “packets”
Programs written in “C”
Point-to-point
algorithm - Stage 1

Purpose: Sender needs to make sure
that the receiver is actually “there” (i.e.
switched on and working properly)

Action: sends a small amount of
“standard” data - usually one byte,
known in ASCII terms as SYN
ASCII code 22 (binary 00010110)
Point-to-point - Stage 2
Purpose: Receiver needs (if it can!) to
reply to the senders ACK signal
 Action

EITHER replies with a positive
acknowledgement ACK, “I’m ready!” ASCII
code 6 (binary 00000110)
OR replies with a negative
acknowledgement NAK, “Not ready!” ASCII
code 21 (binary 00010101)
Point-to-Point: Stage 3

Purpose
 sender reacts to the reply (or not) from the
receiver by either closing down or sending a
“preamble”

Action
 IF sender
EITHER does not receive acknowledgement
OR receives a NAK response…

THEN it closes down the communication, with an error message
 ELSE, it sends out a further set of data, known
as a preamble…
Point-to-point - Stage 4

Purpose
synchronise protocols (receiver)
1. processes the preamble
contains data telling the it which comms
protocol, error control, flow rate, encrypt,
etc. the sender would like to use
2. passes short message back to the
sender
indicates whether it will be able to
understand and handle data in that form
Point-to-point – Stage 5
Purpose: (sender) establish or close
down the communications channel
 if response received is negative (ie
receiver can’t handle data in that format):

THEN the communication is closed down
with an error message (e.g. NAK)
ELSE, a communications “channel” is
established
Point-to-point - Stage 6

Purpose:
 sending data & error checking info in
blocks/packets according to the format
agreed in the preamble
would take much too long to send and
receive data one byte at a time!

Action:
Sender sends one block/packet followed by
error checking info
Point-to-point - Stage 7
Purpose: using results of processing the
error checking info to request next
packet or resending of same packet
 Action:

Receiver compares error checking info with
that already obtained in the block/packet
» if an error is detected request to resend
block/packet
» else request to send NEXT packet
Point-to-point - Stage 8
Purpose: sending the rest of data…
 Action: process or sending/resending
continues (loops…) until all the data is
satisfactorily received
 Note: a poor communications
environment will result in a lot of
errors/resending

which will slow down communications…
BUT the data will still get through…
Point-to-point - Stage 9


Purpose: close down the communications
channel
Action:
 when no further data is available to send and the
final packet/block has been acknowledged…
 the sender sends an EOT (end of transmission)
byte ASCII 4 binary 00000010
 this terminates the communications channel!
Techniques for
Detecting/Managing Errors

Many error detection and correcting
techniques are available
 process normally involves
» sending of the main block
» Sending of further information
» calculation based on recreating the additional
information from the main block
» comparison of the two
 choice must be appropriate for speed,
cabling, protocol type, etc
Flow Control


A feedback mechanism between sender and
receiver so that the receiver can inform the
sender if it is not keeping up
Usually achieved by “synchronization” bits or
byte (ASCII SYN)
 a pause in the communication can occur if necessary
» e.g. if buffer becomes full
» gives time for buffer to empty…
 sender will not send any more data until it gets the “all
clear” from the receiver
Further point-point issues

Programming code could be added to the
basic algorithm which would enable:
a series of protocols to be tested during
handshaking
packets to travel through analogue as well as
digital media
packets to be converted from one format to
another before/after transmission
extra processing to check for virus footprints
So what about networks?


All this is needed just to send data from one
computer to another, without any routing!
If the computer is on a network, the following
additional factors immediately need to be
taken into consideration:
 naming of computers
 addressing (if on a different network or segment)
More factors for a
network protocol?



Logging on/off and access rights
Packet switching or circuit switching
Navigation:
 type of routing algorithm if circuit switching
 creation of packets if packet switching
 mopping up lost packets


Packet reassembling at destination…
CONCLUSION: A NETWORK PROTOCOL IS A
COMPLEX PIECE OF PROGRAMMING