lab10 appendix e - Kuroski.net

kindlyminnowΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

82 εμφανίσεις

Appendix E

An introduction to the
cnet

network simulator

cnet

is a network simulator which enables experimentation with various data
-
link layer, network layer, routing
and transport layer networking protocols in networks consisting of any combination of point
-
to
-
poin
t links and
IEEE

802.3 Ethernet segments. With reference to the OSI/ISO Networking Reference Model,
cnet

provides the
Application and Physical layers. User
-
written protocols are required to ``fill
-
in'' any necessary internal layers
and, in particular, to o
vercome the corrupted and lost frames that
cnet
's Physical Layer randomly introduces. In
addition, advanced users may develop different Application and Physical Layers which exhibit varying
statistical characteristics of message generation and data transmi
ssion. Simulation sizes may range from two to
a few hundred nodes.

cnet

either displays the entire network under Tcl/Tk or runs rather less visually on an ASCII terminal. Under
Tcl/Tk,
cnet

provides a graphical representation of the network under executio
n and permits a number of
attributes of the network to be modified while the simulation is running. Nodes may be selected with the mouse
to reveal a sub
-
window displaying the output and protocol statistics of that node. Some of the node's attributes,
such
as message generation rates and sizes, may be modified while the network is running by selecting choice
buttons. Similarly, the default attributes of all nodes in the network may be simultaneously modified by
selecting and changing global attributes. From
another menu, each node may be forced to reboot, (impolitely)
crash, (politely) shutdown and reboot, pause and (hardware) fail.


This is a typical starting representation of
a two node simulation, here implementing the
stop
-
and
-
wait

protocol.
The simulation is currently running but we could pause and then single
-
step through our protocol using the
buttons. A total of 82292 messages have been delivered so far, and the Applicati
on Layer has not been
presented with any ``incorrect'' messages. Our protocol is thus reported as being 100% correct.

Appendix E


Here we've clicked on on
e of the nodes to display its output window. All output on each node's output window
is generated by calling C's
printf()

function in the protocol code. Here we see an annotation of the
stop
-
and
-
wait

protocol. The text on the first of the five central butt
ons has also been defined by the protocol code. If this
button is selected, execution will transfer to code provided by the student's code, perhaps for debugging. An
output window is available for each node, even in large simulations.

Appendix E


Selecting a link results in a sub
-
window being displayed which shows transmission statistics for that link. Links
are bidirectional, so ``selecting a link'' means c
licking on the link close to its source node. The link
-
based
attributes of transmission costs and error probabilities may be modified while the network is running by
dragging sliders. Similarly, the attributes of all links in the network may be simultaneou
sly modified by
selecting and changing global link attributes.

cnet

is able to automatically detect and report a wide variety of errors commonly made by undergraduate
students when developing their protocols. These include invalid arguments passed to func
tions, an incorrect
specification of links, addresses and timers, undetected message corruption or loss, messages passed to incorrect
destinations, out
-
of
-
sequence or duplicated messages, etc. As shown in the following image, errors are reported
in a popup
-
window describing the error and its location in the student's source code (here, the previous line has
deliberately caused the error, and by calling
CHECK

we detect and report the ill
-
effect).

Appendix E


cnet

can present a limited visualization of data frames traversing the Physical Layer. Using simple rectangles,
colours, and short strings, it is possible to display both data and acknowledgment frames, and
the contents of
some of their fields. In combination, these features may be used to debug implementations of Data Link Layer
protocols. Below, we see a selective
-
repeat protocol experiencing frame loss (the upper ghostly white data
frame number 5) and fram
e corruption (the singed grey data frame number 3), while other data and
acknowledgment frames are also being exchanged.


cnet

requires networ
k protocols to be written in the ANSI
-
C programming language and supports their
execution within a single UNIX or Linux process. A standard compiler, preferably
gcc
, is used to compile the
Appendix E

user
-
written protocol code. The compiled code is then dynamically l
inked at run
-
time with the
cnet

simulator.
Protocols are invoked directly by
cnet

itself
-

they are not interpreted. By design, the protocols do not need to
contain any windowing code.


As of version 2.0,
cnet

supports IEEE

802.3 Ethernet segments as well as its traditional point
-
to
-
point WAN
links. Each segment consists of two or more Network Interface Cards (NICs) that connect host or router no
des
to the segment. Large networks may be constructed by joining multiple Ethernet segments via gateway nodes
and wide
-
area point
-
to
-
point links. Each NIC's own address is initially defined in the topology file, in the 6
-
byte
hexadecimal format of traditio
nal Ethernets, and
cnet

provides functions to configure each NIC's address, and to
set a NIC into promiscuous mode. The simulation of Ethernets is reasonable, but not perfect.
cnet

supports a
fixed transmission rate of 10Mbps, a slot
-
time of 52usecs, broad
cast addressing, collision detection, jamming,
and binary exponential backoff, but does not support jitter control nor multicast addressing.

Appendix E


T
he
current

values of the node and link attributes (as possibly modified via the windowing interface) are
available to the protocol code each node in
C

data structures and variables. These structures and variables are
declared in
cnet
's header file
<cnet.h>
, which is included in each node's protocol code. These structures and
variables are initialized when each node is rebooted and updated as each node is scheduled for execution. Their
values are considered as
read
-
only

and cannot be (successfully) modified
directly by the protocols. They may,
of course, be modified via the windowing interface.

Appendix E


Costs or weights may be assigned to each link, to represe
nt the cost of transmitting each frame, or the number of
bytes in each frame. Protocols may then be developed to deliver network traffic which either minimize the total
cost, or maximize the total flow.


Appendix E

And when you believe that you have your protocols working, run them with
cnet
's
-
r

option to generate a
random, connected, topology.