-
Context
level diagram
The context level object model, which is attached to this document,
gives an overview of the GNAT’s internal structure. The user interacts
with the software via the GUI, which presents a standard windows-style
interface, making use of dialog boxes, pull-down menus, etc. The GNAT will
be able to output an ASCII-text file which contains analysis data in human
readable form. This is useful if the user wishes to save the results of
some analysis or a listing of network packets which the user deems relevant.
The GNAT takes its input solely from the Snoop file, which contains
a trace of all packets as they were captured from the network which is
being studied. Once a user opens a Snoop file, the software will parse
the Snoop file, extract all packets and perform various analyses, as stated
in the specifications document.
The analyses and results will be stored in various classes which are
designed to process network packet data. The CheckSums, ZeroWindow and
Retransmissions classes will maintain data about packets which have bad
checksums, zero windows and have been retransmitted, respectively. The
PacketList class will store a list of all the packets contained within
the Snoop file. This class will represent the entire Snoop file, but with
only the data which is relevant to the analyses performed by the GNAT.
-
Data
Dictionary
-
CheckSums – Stores a list of PacketReference objects
which refer to packets with bad checksums. Also contains a list of Connection
objects which store data about connections on which packets with bad checksums
were generated. This class interacts with the PacketList class and the
GUI. When a new Packet is added to the PacketList, it calls a method in
CheckSums which verifies the checksums of the packet. If the checksum is
not correct, the CheckSums class adds a PacketReference object to its own
list and set the Corrupted attribute in the Packet to TRUE. Also, when
the user wants to see the packets with bad checksums, the GUI interacts
with the CheckSums class to obtain the data. Finally, CheckSums can interact
with the output file to generate ASCII text output.
-
Connection – Stores data related to TCP/IP connections which are
detected in the Snoop file. When a new connection is detected in the Snoop
file during parsing, a new Connection object is constructed and the sockets
at both ends of the connection are stored. This class interacts with the
CheckSums, ZeroWindow, Retransmission and PacketList classes, as all of
these classes contain lists of Connections.
-
GUI – The GUI interacts with the user and displays analysis data
in graphical and textual form. The user can use pull-down menus to make
selections as to what he/she wishes to see. The GUI then interacts with
the CheckSums, ZeroWindow, Retransmissions and PacketList classes to get
the data which it needs to display. The GUI then takes the data given to
it by whichever class it consulted and displays it appropriately (bar graph,
histogram, etc.)
-
List – This is a superclass from which CheckSums, ZeroWindow, Retransmission
and PacketList inherit. It contains the attributes and methods which are
common to all four of these classes. An object of this class will never
be declared, so it won’t directly interact with other objects. For interactions
involving classes which inherit from it, see CheckSums, ZeroWindow, Retransmissions
and PacketList.
-
Node – This is a superclass from which PacketReference and Packet
classes inherit. It contains the attributes and methods which are common
to these two classes. An object of this class will never be declared, so
it won’t directly interact with other objects. For interactions involving
classes which inherit from it, see PacketReference and Packet.
-
Outputfile – This class is able to write out various data in ASCII
text format. If the user wishes to save certain analysis data for later
review, he/she can choose to do so. Outputfile can obtain either analysis
data or packet data and write this into a text file. Since this class primarily
obtains data for writing, it interacts with the classes which inherit from
List.
-
Packet – This class stores all the relevant data about a packet
which is stored in a Snoop file. As the Snoop file is parsed, a list of
Packets is built and stored in the PacketList class. A Packet object will
exist only within the PacketList, so Packets only interact with this class.
-
PacketList – This class is the workhorse of the program. Its constructor
will be responsible for parsing the Snoop file, creating a list of Packet
objects and informing CheckSums, ZeroWindow and Retransmissions classes
that they should examine a new Packet for the data each is concerned with
(ie: CheckSums verifies that the checksum is correct). During parsing,
PacketList also determines when connections are opened and closed and creates
a list of Connection objects to store data about every connection encountered
in the Snoop file. PacketList obviously interacts with CheckSums, ZeroWindow
and Retransmission classes, and it also interacts with the GUI and output
file.
-
PacketReference – This contains a reference to a Packet object.
This class will be used within CheckSums, ZeroWindow and Retransmission
classes to store references to packets which are relevant. For example,
the ZeroWindow class will contain a list of PacketReferences which refer
to Packets which have a window field of zero. The Packets which PacketReferences
refer to will be stored in the PacketList class. Since this class will
be used only in the CheckSums, ZeroWindow and Retransmission classes, it
will interact only with these classes.
-
Retransmissions - Stores a list of PacketReference objects which
refer to packets which were retransmitted. Also contains a list of Connection
objects which store data about connections on which retransmitted packets
were generated. This class interacts with the PacketList class and the
GUI. When a new Packet is added to the PacketList, it calls a method in
Retransmissions which checks to see if the packet was retransmitted. If
so, the Retransmission class adds a PacketReference object to its own internal
list. Also, when the user wants to see the packets which were retransmitted,
the GUI interacts with the Retransmissions class to obtain the data. Finally,
Retransmissions can interact with the Outputfile class to generate ASCII
text output.
-
Snoopfile – This class will not be coded by the team. Instead, this
class represents the physical Snoop file which provides the input to the
GNAT. The Snoop file contains two important attributes, other than its
filename. It contains a header which identifies it as a Snoop file, version
2, and it contains a sequence of packets which were recorded from an Ethernet-based
TCP/IP network. This class will interact only with the PacketList class,
as PacketList is responsible for parsing the Snoop file and extracting
all relevant data.
-
ZeroWindow - Stores a list of PacketReference objects which refer
to packets which show zero in the TCP header’s window size field. Also
contains a list of Connection objects which store data about connections
on which zero window packets were generated. This class interacts with
the PacketList class and the GUI. When a new Packet is added to the PacketList,
it calls a method in ZeroWindow which checks to see if the packet has a
zero window. If so, the ZeroWindow class adds a PacketReference object
to its own internal list. Also, when the user wants to see the packets
which were retransmitted, the GUI interacts with the ZeroWindow class to
obtain the data. Finally, ZeroWindow can interact with the Outputfile class
to generate ASCII text output.
-
-
OMT Diagrams
-
Object Model – This model describes the objects which make up the GNAT.
The most critical section of this model is the classes which inherit from
the List class. These classes store data regarding packets which have certain
attributes and this data is later used to compute various statistics which
may be of interest to the user. The most important class in this diagram
is the PacketList class, as this is responsible for parsing the Snoop file
and extracting and storing data about each packet which it encounters.
-
Dynamic Model – The model titled Event_Flow_Diagram gives a complete
description of the flow of events in the GNAT. This model is fairly straightforward.
The diagrams labeled event2 and eventexceptions are event trace diagrams,
showing all of the events which can occur within the GNAT. These also are
straightforward, with the event2 diagram showing interactions in the ideal
scenario, whereas eventexceptions show events which occur when an error
is encountered. The most common errors we expect the software to encounter
are a file which is not a Snoop file and errors while parsing the Snoop
file. In the event that the user chooses to open a file which is not a
Snoop file, the GNAT will detect that the file does not contain the proper
header for a Snoop file (see RFC 1761) and will give the user a warning.
Also, the GNAT may encounter problems while parsing a Snoop file. This
may result from a Snoop file which contains unexpected data (ie: a Snoop
file generated on a network which was not a TCP/IP network) or from a bug
in the parsing algorithm, although we hope to eliminate all of these by
the first release of the software. If the GNAT does encounter a parsing
error, it will give the user a warning of the error.
-
Functional Model – The model titled context-level gives a very high
level view of the system, showing input coming from the user and the Snoop
file and output going back to the user and to the output file, which will
be a text file which can contain packet information or analysis results.
The level 1 diagram, entitled dfd-level1, shows a breakdown of the basic
functional units within the GNAT. Primarily, the software will parse the
Snoop file to extract packet data, construct mini packets (these will be
Packet objects as described in the Data Dictionary), and analyze these
packets. The user can then choose to see graphs of the results, or write
data out to the output file.